Memory leaks in .NET [closed]

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

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 3

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 4

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

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.