Although the .NET Framework takes the memory management task out of your hands, there are still a few things that you must pay attention to when disposing of an object in order for the Garbage Collector to do its work properly.
You would think that once you remove the reference from an object it will eventually be collected by the Garbage Collector, that’s almost true. The fact is that, if that object was registered to an event published by another object, it won’t be collected by the Garbage Collector.
Why you ask? Allow me to explain.
When you register to an event you provide a delegate, and that in fact acts as a reference from the object that published the event to the registering object. So in order to make the GC collect the registering object, you must unsubscribe from all the events. Otherwise there is still a reference to that object in the form of that delegate.
To sum things up, the safest way to ensure that an object will be collected by the GC is to make it inherit IDisposable and in the Dispose method unsubscribe from all the events you were subscribed to.
Subscribe to our feed and get the complete code sample for this article
Amit
By Chris Carter on Mar 17, 2008 | Reply
Please post something tangible that shows how you came to this conclusion. What tool did you use to determine what was left in memory?
By Damien Guard on Mar 17, 2008 | Reply
This is a known problem with this pattern and GC based systems under the name lapsed listeners.
You can’t always remove from the event mechanism if the objects are managed elsewhere and it doesn’t provide a facility to do so - e.g. TreeView control.
Thankfully .NET 3.5 has a WeakEventManager class that can provide event services without this problem by keeping weak references to the listeners.
[)amien
By Jason Kealey on Mar 17, 2008 | Reply
I ran into this very same issue last week.
Here’s how I discovered the source of the issue:
http://blog.lavablast.com/post/2008/03/How-I-lost-my-WinDbg-virginity.aspx
By Razan Paul on Mar 17, 2008 | Reply
It sounds bad.It is not a memory leak problem.
Don’t waste other’s time.
By rekna on Mar 17, 2008 | Reply
Can you give a small code example?
By Admin on Mar 17, 2008 | Reply
To Razan
Of course it is a memory leak you think you have disposed of an object but infact you didnt
and if this object takes alot of memory you are in a jam
By Admin on Mar 17, 2008 | Reply
To Chris
You dont need a tool or anything you can just see that in debug mode the “Disposed Object” keeps getting event, and therefore still lives
I will post some code to demonstrate the matter.
Amit
By JV on Mar 17, 2008 | Reply
I agree with Razan that it isn’t a memory leak problem. A memory leak is caused by something which is still active in memory, but already should have been gone. Well, this is not the case here, because there still is a valid reference available. So no problem here, just something tricky which you should keep in mind.
By Admin on Mar 17, 2008 | Reply
But this is exactly what that is, an object in the memory YOU thought you released, but in fact you did not, the object will keep on responding to events and make you application do unexpected things and of course keep holding resources. too many object like this and you will run out of memory, that is exactly what a memory leak is
Amit
By Admin on Mar 17, 2008 | Reply
I have added an exmaple project to illustrate it
By FellowBlogger on Mar 17, 2008 | Reply
Terrific article! FYI, it is a violation of Google AdSense Terms of Service to place images next to your Google ads. If Google reviews your site, they may ban you from AdSense. This happened to a friend of mine, and it took him two months to restore his Google AdSense, so be warned!