Dealing with Memory Leaks in .NET

Posted by Abel Avram on Nov 05, 2009

Sections

Development,

Architecture & Design

Topics

.NET ,

Programming

Tags

Memory Leaks ,

GarbageCollection

Fabrice Marguerie, a software architect and consultant, wrote the article How to detect and avoid memory and resources leaks in .NET applications, published on MSDN. The article explains how memory and resource leaks can happen while programming for .NET and how to avoid them.

Languages like C#, doing house cleaning through a memory garbage collector, do not have memory leaks in its original sense when a program loses complete access to a memory location. According to Fabrice, memory leaks take place when a memory location is no longer needed but the program continues to keep at least one reference to it. The garbage collector would reclaim that memory if it was unreachable, but the memory becomes a leak as long as it is referenced by the program but not used.

Fabrice also lists a number of OS resources which can be subject to similar leaks:

• The system uses User objects to support window management. They include: Accelerator tables, Carets, Cursors, Hooks, Icons, Menus and Windows.
• GDI objects support graphics: Bitmaps, Brushes, Device Contexts (DC), Fonts, Memory DCs, Metafiles, Palettes, Pens, Regions, etc.
• Kernel objects support memory management, process execution, and inter-process communications (IPC): Files, Processes, Threads, Semaphores, Timers, Access tokens, Sockets, etc.

These resources are limited, the registry keys GDIProcessHandleQuota and USERProcessHandleQuota containing the maximum number of GDI and user objects a process can use. The default values are 10,000 for these handles. While the number is enough for most applications, using too many of them will make the system reach another limit of 65,536 handles for a Windows session. Fabrice reported hitting that limit a lot sooner, at about 11,000. His conclusion is that systems resources need to be carefully used and freed when no longer needed.

Fabrice lists the following root causes for leaks explaining how each of them works:

• Using static references
• Event with missing unsubscription – these are considered by the author to be the most common source of leaks
• Static event with missing unsubscription
• Not invoking the Dispose method
• Using an incomplete Dispose method
• Misusing BindingSource  in Windows Forms
• Not using Remove call on WorkItem/CAB

The author continues the article by offering advice on how to avoid leaks:

• the creator or owner of an object, not its user, is responsible for disposing it
• always unsubscribe an event listener when it is not longer needed; it could be done in Dispose() for safety
• when an object no longer generates events, all its listeners should be removed by assigning null to the object
• when a reference is used by a model and its view, it is recommended to pass a clone of the referenced object to the view to avoid losing track of who’s using what
• calls to system resources should be enclosed in using blocks which automatically force a Dispose call when leaving the block

Fabrice concludes by introducing a number of useful tools for dealing with objects and leaks: GDILeaks (EXE), dotTrace, .NET Memory Profiler, SOS.dll, WinDbg.

1. Back to top

   I would add...

   by Francois Ward

   The most common case that I've seen as an ASP.NET development is the caching of complex UI objects (which should never be done), since these have references to nearly everything in the application life cycle, causing entire contexts to stay in memory.
   
   Also, i think no discussion about .NET memory leak (or Java, for that matter) is complete without talking about WeakReferences (references that allow the garbage collector to clean the objects if no other references are found)

   Reply

2. Back to top

   Re: I would add...

   by Fabrice Marguerie

   I'll give more cases soon on my blog, based on what I've discovered since I wrote this article.
   
   WeakReferences are covered in the article, even if I just give a hint at them.

   Reply

3. Back to top

   French version

   by Fabrice Marguerie

   A French version of this article is available: Détecter et éviter les fuites de mémoire et de ressources dans les applications .NET.

   Reply

• Older >