BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Dealing with Memory Leaks in .NET

Dealing with Memory Leaks in .NET

Leia em Português

This item in japanese

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 ProfilerSOS.dll, WinDbg.

Rate this Article

Adoption
Style

BT