nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any way to check whether a COM ArcObjects object is already released?

SuiHuang

Hi Everybody:

    I found that after an ArcObject COM object is release, some operations such as checking interface cannot be performed on it and otherwise it will throw exception.
    Is there any way for me to detect whether the object has already been release? I am trying not to use the TRY-CATCH pair to handle this logic...
    Thank you.

**************** Released twice by my utility function ******
    IPoint obj = new PointClass();
    ReleaseObjects(obj);
    ReleaseObjects(obj);

**************** Utility functions *********
        public void ReleaseObjects(params object[] comObjList)
        {
            foreach (object obj in comObjList)
            {
                if (obj != null)
                {
                    if (obj is System.Collections.IEnumerable)
                    {
                        ReleaseComs(obj as IEnumerable);
                    }
                    else
                    {
                        Marshal.ReleaseComObject(obj);
                    }
                }
            }
        }

        private void ReleaseComs(IEnumerable Objects)
        {
            foreach (object obj in Objects)
            {
                if (obj != null)
                {
                    if (obj is IEnumerable)
                    {
                        ReleaseComs(obj as IEnumerable);
                    }
                    else
                    {
                        Marshal.ReleaseComObject(obj);
                    }
                }
            }
        }

Find more posts tagged with

Accepted answers

AlexanderGray

Using releaseComObject is necessary in .NET code because some objects' reference count don't decrement when they go out of scope and don't get collected in GarbageCollection. This is a problem for cursor because you can exceed the number of open cursors you are allowed to have. It is also a problem with featureclasses and workspaces and other geodatabase objects that maintain locks until they are explicitly release.
If you set your variable to null after calling the release you should be able to test to see if the variable is null and avoid calling it a second time. Aside from that I would only suggest keeping a tighter control on the variables to avoid release being called a an object separated from the RCW.

All comments

NeilClemmons_GISinc

The exception is not caused by calling a method of that released COM object, but caused by releasing it again with my generic releasing method... it use "if (obj is IEnumerable)" to check the interface it supports. Because it is already released, the checking will fail in the second call of the releasing method.

Now I decide to resolve this issue by coding carefully, not to release the same COM object twice, even though the logic will be a bit more comoplicated.

Set the object to null after the call to ReleaseComObject. After the object is released, it's value isn't null so if you call the method again it will try to release it again. If you set the object to null after releasing it then the next time you call the method it will see the object is null and not try to release it a second time.

Also, as you said, more careful programming is what you really need. You should be releasing objects when you're done with them. This is usually right before they go out of scope so in reality there shouldn't be another place in the code where you would even have access to the object in order to try to release it.

SuiHuang

For some reason, your statement is leading me to believe that you are releasing an object, then trying to do a method call on that object, but first checking whether the object you released is null, otherwise calling that method on a released object without first re-assigning that released object the value of null is giving you the exception. What do you expect? If you were in Java, assigning an object reference to null would still give you an exception when you tried calling a method on that object.

I still don't understand why you are trying to call a method on an object after you've released it. Can anyone explain that to me? I would really like to understand why you are trying to do this.

The exception is not caused by calling a method of that released COM object, but caused by releasing it again with my generic releasing method... it use "if (obj is IEnumerable)" to check the interface it supports. Because it is already released, the checking will fail in the second call of the releasing method.

Now I decide to resolve this issue by coding carefully, not to release the same COM object twice, even though the logic will be a bit more comoplicated.

LeoDonahue

For some reason, your statement is leading me to believe that you are releasing an object, then trying to do a method call on that object, but first checking whether the object you released is null, otherwise calling that method on a released object without first re-assigning that released object the value of null is giving you the exception. What do you expect? If you were in Java, assigning an object reference to null would still give you an exception when you tried calling a method on that object.

I still don't understand why you are trying to call a method on an object after you've released it. Can anyone explain that to me? I would really like to understand why you are trying to do this.

SuiHuang

If you are releasing fList and f at the end of your procedure/function/method - whatever, how are you getting an exception?

Also, telling us what kind of exception you're getting would help. Is it NullPointerException? AutomationException? something else?

Hi Idonahue:

The exception message tells "COM object that has been separated from its underlying RCW cannot be used."
Any idea? Thank you!

LeoDonahue

If you are releasing fList and f at the end of your procedure/function/method - whatever, how are you getting an exception?

Also, telling us what kind of exception you're getting would help. Is it NullPointerException? AutomationException? something else?

SuiHuang

Not to nitpick, but if you set a reference to null *after* you have explicitly released it, what other value to expect it to have when you test it for null?

Is Sui trying to call a method on that Object just before it is actually killed off? Not a good idea.

Here is a sample senario:
*******************************
List<IFeature> fList = ...
int i = ...
IFeature f = null;
if (...)
{
f = fList
}
else if
{
f=...
}

//release fList
//release f
*******************************

In the above case if I release everything in fList without assigning null and f=fList was executed, then I will get exception.

LeoDonahue

If you set your variable to null after calling the release you should be able to test to see if the variable is null and avoid calling it a second time.

Not to nitpick, but if you set a reference to null *after* you have explicitly released it, what other value do you expect it to have when you test it for null?

Is Sui trying to call a method on that Object just before it is actually killed off? Not a good idea.

LeoDonahue

Just because I am releasing it intentionally, I need to care. Because the current way I am structuring the code doesn't support double releasing. Releasing a released COM object will throw exception.

If you, as the programmer, decided to release an object reference, why do you want to know if it has been released or not? Create a new object.

SuiHuang

Using releaseComObject is necessary in .NET code because some objects' reference count don't decrement when they go out of scope and don't get collected in GarbageCollection. This is a problem for cursor because you can exceed the number of open cursors you are allowed to have. It is also a problem with featureclasses and workspaces and other geodatabase objects that maintain locks until they are explicitly release.
If you set your variable to null after calling the release you should be able to test to see if the variable is null and avoid calling it a second time. Aside from that I would only suggest keeping a tighter control on the variables to avoid release being called a an object separated from the RCW.

Thank you! Seems then assigning null value and avoid calling a second time are the only available ways to go.

SuiHuang

Personally, I don't think you should care whether it has been released or not after the fact, because you would be the person who is releasing it intentionally or via the the way you are structuring your code.
[/url]

Just because I am releasing it intentionally, I need to care. Because the current way I am structuring the code doesn't support double releasing. Releasing a released COM object will throw exception.

AlexanderGray

LeoDonahue

Is there any way for me to detect whether the object has already been release?

What are you trying to do?

If .NET Garbage collection works the same way as it does in Java, then when an object variable goes out scope, or you set it to null or you assign it another reference, then the object becomes eligible for garbage collection, but you don't know when exactly that happens in the run time environment.

Personally, I don't think you should care whether it has been released or not after the fact, because you would be the person who is releasing it intentionally or via the the way you are structuring your code.

Maybe this link describes what you want to do: http://edndoc.esri.com/arcobjects/9.2/NET/fe9f7423-2100-4c70-8bd6-f4f16d5ce8c0.htm#ReleaseComObject

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.