Memory leaks in .NET

Question

What are all the possible ways in which we can get memory leaks in .NET?

I know of two:

1. Not properly un-registering Event Handlers/Delegates.
2. Not disposing dynamic child controls in Windows Forms:

Example:

// Causes Leaks  
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  

// Correct Code  
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  
label.Dispose();

Update: The idea is to list common pitfalls which are not too obvious (such as the above). Usually the notion is that memory leaks are not a big problem because of the garbage collector. Not like it used to be in C++.

Answer 1

There's no way to provide a comprehensive list... this is very much like asking "How can you get wet?"

That said, make sure you're calling Dispose() on everything that implements IDisposable, and make sure you implement IDisposable on any types that consume unmanaged resources of any kind.

Every now and then, run something like FxCop on your codebase to help you enforce that rule - you'd be surprised how deep some disposable objects get buried within an application framework.

Answer 2

Well, there's really no way to answer your question. Failure to release memory during execution is caused by a failure to release any object. There is, literally an infinite number of things you could do to cause that.

Answer 3

@Greg - well yes, but there have to be some which are more common than others. I am trying to compile a best practice list on this topic.

Answer 4

@Vaibhav: The problem is, there is no best practice. Taking your example of controls on a form... although you could say that you "should always" dispose items on your form, if you use the designer, this happens automatically via the inherited dispose method, and in that case you actually shouldn't explicitly dispose anything. Also, the form could be a custom dialog, whose lifetime is short enough to ensure that even though the controls on it are not disposed, the form (which holds those references) is disposed in short order, which makes additional cleanup code pointless.

Your question is too broad, and what you're hoping to achieve is too nonspecific.

Answer 5

Are you talking about unexpected memory usage or actual leaks? The two cases you listed aren't exactly leaks; they are cases where objects stick around longer than intended.

In other words, they are references the person who calls them memory leaks didn't know or forgot about.

Edit: Or they are actual bugs in the garbage collector or non-managed code.

Edit 2: Another way to think about this is to always make sure external references to your objects get released appropriately. External means code outside of your control. Any case where that happens is a case where you can "leak" memory.

MSN

Answer 6

A lot of the things that can cause memory leaks in unmanaged languages can still cause memory leaks in managed languages. For example, bad caching policies can result in memory leaks.

But as Greg and Danny have said, there is no comprehensive list. Anything that can result in holding memory after its useful lifetime can cause a leak.

Answer 7

Calling IDisposable every time is the easiest place to start, and definitely an effective way to grab all the low-hanging memory leak fruit in the codebase. However, it is not always enough. For example, it's also important to understand how and when managed code is generated at runtime, and that once assemblies are loaded into the application domain, they are never unloaded, which can increase the application footprint.

Answer 8

@Mat

Are you talking about unexpected memory usage or actual leaks? The two cases you listed aren't exactly leaks; they are cases where objects stick around longer than intended.

There is no effective difference between the two. Memory that is no longer useful, and remains uncollected is effectively leaked.

---

That's true from that perspective, but if there is an actual leak that isn't based on properly making references go out of scope appropriately, that's fundamentally different from forgetting which references to your objects are still alive.

If you let a disposable reference go out of scope without calling dispose(), then you've potentially leaked unmanaged resources. These can sit unclaimed for an arbitrary amount of time (potentially until your program closes). I consider that a memory leak.

---

Not to be argumentative, but without any context, it doesn't matter. And that particular post is treating memory leak as a global problem, not a localized one. (You can also argue that memory problems are global problems, but you're arguing about something I'm not.)

I don't understand your distinction between global and local problems, nor do I understand why you're even bringing this up. The post I linked is talking about how application behavior (caching) can lead to unexpected behavior (memory leaks). I don't understand what this has to do with any global/local distinction.

Anyways, to rephrase my point, talking about memory leaks is pointless without talking about the types of memory leaks. In this case, it should probably be memory leaks you can fix and memory leaks you can't fix.

Talking about memory leaks you can't fix seems to be a waste of time. If you discover a memory leak that you cannot fix, then the appropriate thing to do is file a bug report, not argue about how to categorize it.

Answer 9

That doesn't really cause leaks, it just makes more work for the GC:

// slows GC
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  

// better  
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  
label.Dispose();

// best
using( Label label = new Label() )
{ 
    this.Controls.Add(label);  
    this.Controls.Remove(label);  
}

Leaving disposable components lying around like this is never much of a problem in a managed environment like .Net - that's a big part of what managed means.

You'll slow you app down, certainly. But you won't leave a mess for anything else.

Answer 10

@Derek: Incorrect. Actual leaked memory remains inaccessible even after the process exits, and cannot be reclaimed, even by the operating system. Uncollected memory will be reclaimed by the OS when the process is closed down.

Answer 11

@Danny - hence I mentioned 'dynamic' controls.

@Mat - you can't really have memory leaks in managed memory... so yes, by memory leaks I mean unintentional usage of memory. for example, the dynamic control problem can cause your Windows Forms application to crash in a hurry.

@everyone - I understand that the topic is broad. So the idea was to get people to point out examples from their experiences. So that a 'watch-out' list could be created.

Answer 12

@Keith

The last one won't work unfortunately (because the add and remove would typically not be in the same place - i showed that only to demo the problem).

Also, it not only slows the GC down, depending on the complexity of the form, you can pretty easily crash the application.

Answer 13

@Vaibhav: If your form is so complex that you use enough handles and memory that you actually crash your application, then it's your design that is at fault, not the memory manager. The memory manager isn't going to help you in this case anyway, since:

1. Your form is visible (I assume)
2. You don't want controls on your visible form to be collected at all.

If you properly clean up after yourself once your form is closed (if it gets closed before exit that is), then all of your controls (whether dynamic or not) will be properly cleaned up when the form goes away.

Answer 14

@Danny

@Derek: Incorrect. Actual leaked memory remains inaccessible even after the process exits, and cannot be reclaimed, even by the operating system. Uncollected memory will be reclaimed by the OS when the process is closed down.

On a modern operating system, processes cannot leak memory after they are shut down. You can allocate all the memory you want, open all the sockets and file handles that you desire, create all the windows and menus that you can, and when your program closes, your resources will be reclaimed by the operating system. Any memory that remains unclaimed after your program closes (with very few exceptions¹) indicates an operating system bug.

¹ One such exception would be the clipboard. Memory handed off to the clipboard may remain allocated after your program exits, by design.

@Derek: You're correct, of course. Perhaps I should have said "have the potential to become inaccessible to the operating system" or some such. We're not necessarily talking about a modern operating system if we're talking about an unmanaged memory leak. It could just as easily be a legacy Win31 system (don't laugh, I've seen those).

Also, some embedded systems don't have the type of robust memory managers that desktop operating systems do, and are absolutely capable of leaking unreclaimable (if that's a word) memory system-wide, even if a process that leaks is shut down. Try a badly-written iPhone application to see a good example of that.

We're talking about .Net here. I agree on some systems it's vital that every program frees its own resources properly. .Net doesn't run on those platforms, though (that I know of).

Answer 15

@Keith

Leaving disposable components lying around like this is never much of a problem in a managed environment like .Net - that's a big part of what managed means.

You'll slow you app down, certainly. But you won't leave a mess for anything else.

To my knowledge, .Net makes no guarantees about GC timeliness, which means your disposable components could be sitting indefinitely. There are several types of native handles (e.g. device context handles) which are fairly tightly constrained. And because these are unmanaged resources, an allocation failure will not trigger a garbage collection cycle. So leaking disposable objects can cause problems, and not just application slowdowns.

Answer 16

Exceptions in Finalise (or Dispose calls from a Finaliser) methods that prevent unmanaged resources from being correctly disposed. A common one is due to the programmer assuming what order objects will be disposed and trying to release peer objects that have already been disposed resulting in an exception and the rest of the Finalise/Dispose from Finalise method not being called.

Answer 17

@Derek

There is no effective difference between the two. Memory that is no longer useful, and remains uncollected is effectively leaked.

That's true from that perspective, but if there is an actual leak that isn't based on properly making references go out of scope appropriately, that's fundamentally different from forgetting which references to your objects are still alive.

MSN

Answer 18

@Derek

There is no effective difference between the two. Memory that is no longer useful, and remains uncollected is effectively leaked.

There is a difference.

If I have a reference to something--even if I only have that reference accidentally (due to an event handler, say)--and that thing consequentially isn't collected, it hasn't been leaked. It doesn't matter that it's not "useful"; it's not leaked; I can still get to it and use it, so it hasn't been lost.

A leak only occurs when memory that isn't referenced doesn't get collected. That can happen with unmanaged code trivially (e.g. by discarding the result of new/malloc), but if it happens to managed code, it is usually demonstrative of a bug in the VM.

I say "usually" because it's possible that the VM doesn't promise exact collection of, for example, the current execution frame. This normally isn't a problem, but can be if the current frame has a (possibly spurious) reference to some large resource, and if the current execution frame remains current for a long time (e.g. while(true) {} ).

Answer 19

@Derek: You're correct, of course. Perhaps I should have said "have the potential to become inaccessible to the operating system" or some such. We're not necessarily talking about a modern operating system if we're talking about an unmanaged memory leak. It could just as easily be a legacy Win31 system (don't laugh, I've seen those).

Also, some embedded systems don't have the type of robust memory managers that desktop operating systems do, and are absolutely capable of leaking unreclaimable (if that's a word) memory system-wide, even if a process that leaks is shut down. Try a badly-written iPhone application to see a good example of that.

Answer 20

@DrPizza

There is a difference.

If I have a reference to something--even if I only have that reference accidentally (due to an event handler, say)--and that thing consequentially isn't collected, it hasn't been leaked. It doesn't matter that it's not "useful"; it's not leaked; I can still get to it and use it, so it hasn't been lost.

A leak only occurs when memory that isn't referenced doesn't get collected. That can happen with unmanaged code trivially (e.g. by discarding the result of new/malloc), but if it happens to managed code, it is usually demonstrative of a bug in the VM.

I say "usually" because it's possible that the VM doesn't promise exact collection of, for example, the current execution frame. This normally isn't a problem, but can be if the current frame has a (possibly spurious) reference to some large resource, and if the current execution frame remains current for a long time (e.g. while(true) {} ).

All you've done is define "memory leak" to refer exclusively to VM bugs. This definition is inaccurate, but mostly it's just not useful. All this definition does is make it harder to talk about programmer-induced memory leaks, which are far more abundant, and thus far more important.

I gave a link earlier to Raymond Chen's post, A cache with a bad policy is another name for a memory leak. This is a great example of why your definition is flawed. You can hold references to memory and still have that memory effectively leaked. If your program exhibits the behavior of a memory leak, then you have, in fact, effectively leaked memory.

You can try to define "memory leak" to exclude this, but your definition is not supported by the rest of the industry. For example, see again Chen's post. Also please note that Chen has been described by Spolsky as "the best programmer in the world" because he's freaking awesome. I'm going to go with his definition over yours, because his definition is useful.

Answer 21

@Derek

You can try to define "memory leak" to exclude this, but your definition is not supported by the rest of the industry.

Not to be argumentative, but without any context, it doesn't matter. And that particular post is treating memory leak as a global problem, not a localized one. (You can also argue that memory problems are global problems, but you're arguing about something I'm not.)

Anyways, to rephrase my point, talking about memory leaks is pointless without talking about the types of memory leaks. In this case, it should probably be memory leaks you can fix and memory leaks you can't fix.

MSN

Answer 22

Call Dispose() if your object implements IDisposable.

Answer 23

Great discussion guys, but let me clarify... by definition, if there is no reference left to an object in .NET, it will be Garbage Collected at some time. So that is not a way to induce memory leaks.

In the managed environment, I would consider it a memory leak if you had an unintended reference to any object that you aren't aware of (hence the two examples in my question).

So, what are the various possible ways in which such a memory leak can happen?

Answer 24

Block the finalizer thread. No other objects will be garbage collected until the finalizer thread is unblocked. Thus the amount of memory used will grow and grow.

Further reading: http://dotnetdebug.net/2005/06/22/blocked-finalizer-thread/

Answer 25

Deadlocked threads will never release roots. Obviously you could argue that the deadlock presents a bigger problem.

A deadlocked finalizer thread will prevent all remaining finalizers to run and thus prevent all finalizable objects from being reclaimed (as they are still being rooted by the freachable list).

On a multi CPU machine you could create finalizable objects faster than the finalizer thread could run finalizers. As long as that is sustained you will "leak" memory. It is probably not very likely that this will happen in the wild, but it is easy to reproduce.

The large object heap is not compacted, so you could leak memory through fragmentation.

There are a number of objects which must be freed manually. E.g. remoting objects with no lease and assemblies (must unload AppDomain).

Answer 26

Setting the GridControl.DataSource property directly without using an instance of the BindingSource class (http://msdn.microsoft.com/en-us/library/system.windows.forms.bindingsource.aspx).

This caused leaks in my application that took me quite a while to track down with a profiler, eventually I found this bug report that Microsoft responded to: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=92260

It's funny that in the documentation for the BindingSource class Microsoft try to pass it off as a legitmate well thought out class, but I think they just created it to solve a fundamental leak regarding currency managers and binding data to grid controls.

Watch out for this one, I bet there are absolutely loads of leaky applications out there because of this!

Answer 27

I have an article about memory leaks that sums up common traps and list tools that can help.

Answer 28

1. Keeping around references to objects that you no longer need.

Re other comments - one way to ensure Dispose gets called is to use using... when code structure allows it.

Answer 29

To prevent .NET memory leaks:

1) Employ the 'using' construct (or 'try-finally construct) whenever an object with 'IDisposable' interface is created.

2) Make classes 'IDisposable' if they create a thread or they add an object to a static or long lived collection. Remember a C# 'event' is a collection.

Here is a short article on Tips to Prevent Memory Leaks.

Answer 30

One thing that was really unexpected for me is this:

Region oldClip = graphics.Clip;
using (Region newClip = new Region(...))
{
    graphics.Clip = newClip;
    // draw something
    graphics.Clip = oldClip;
}

Where's the memory leak? Right, you should have disposed oldClip, too! Because Graphics.Clip is one of the rare properties that returns a new disposable object every time the getter is invoked.

Answer 31

I have 4 additional items to add to this discussion:

1. Terminating threads (Thread.Abort()) that have created UI Controls without properly preparing for such an event may lead to memory being used expectantly.

2. Accessing unmanaged resources through Pinvoke and not cleaning them up may lead to memory leaks.

3. Modifying large string objects. Not necessarily a memory leak, once out of scope, GC will take care of it, however, performance wise, your system may take a hit if large strings are modified often because you can not really depend on GC to ensure your program's foot print is minimal.

4. Creating GDI objects often to perform custom drawing. If performing GDI work often, reuse a single gdi object.

Answer 32

Tess Fernandez Has great blog posts about finding and debugging memory leaks. Lab 6 Lab 7