Memory leaks in .NET [closed]

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++.

---

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 1

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 2

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 3

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 4

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 5

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 6

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 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

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 9

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.

Answer 10

3. 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 11

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 12

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

Answer 13

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 14

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).