A .NET MEMORY LEAK YOU DID NOT THINK ABOUT

Directory Freebies VS CheatSheet Forum

RSS

Translate

Home About Archive Privacy Contact Advertise Guest Post

A .NET memory leak you did not think about

Posted by Amit on Mar 16th, 2008 | Filed under .Net |

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

Tags: .Net, Dispose, Event, Framework, Garbage Collector, GC, IDosposable, Object, Reference

16 Responses to “A .NET memory leak you did not think about”

Chris Carter Said on Mar 17, 2008 :

Please post something tangible that shows how you came to this conclusion. What tool did you use to determine what was left in memory?
Damien Guard Said on Mar 17, 2008 :

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
Jason Kealey Said on Mar 17, 2008 :

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
Razan Paul Said on Mar 17, 2008 :

It sounds bad.It is not a memory leak problem.
Don’t waste other’s time.
rekna Said on Mar 17, 2008 :

Can you give a small code example?
Admin Said on Mar 17, 2008 :

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
Admin Said on Mar 17, 2008 :

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
JV Said on Mar 17, 2008 :

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.
Admin Said on Mar 17, 2008 :

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
Admin Said on Mar 17, 2008 :

I have added an exmaple project to illustrate it
FellowBlogger Said on Mar 17, 2008 :

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!