Memory leaks in .NET [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

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

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 2

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 3

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 4

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

Answer 5

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 6

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/