Memory leaks in .NET [closed]

Answer 1

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 2

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 3

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 4

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 5

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

Answer 6

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.