Application for debugging memory leaks: Discovering and preventing memory leaks in managed code

This article discusses:

Understanding memory leak issues in managed applications

unmanaged memory used in. NET applications

Help. NET garbage collector play its due effect

This article uses the following techniques:

The. NET Framework

Directory

Memory in a. NET application

Detect leaks

Stack memory leaks

unmanaged heap memory leaks

"Leaking" managed heap memory

Summarize

When it comes to memory leaks in managed code, the first reaction of many developers is that this is not possible. After all, the garbage collector (GC) is responsible for managing all the memory, right? You know, however, that the garbage collector handles only managed memory. Unmanaged memory is heavily used in applications based on the Microsoft®.net Framework, which can either be used by the common language runtime (CLR) or be explicitly used by programmers when interoperating with unmanaged code. In some cases, the garbage manager seems to be evading its responsibilities and does not effectively handle managed memory. This is usually caused by subtle (and possibly very obvious) programming errors that prevent the garbage collector from working properly. As programmers who often work with memory, we still need to check our own applications to ensure that they do not leak memory and can use the required memory in a reasonable and efficient way.

Memory in a. NET application

You probably already know that there are multiple types of memory to be used in. NET applications, including: stacks, unmanaged heaps, and managed heaps. Here we need a brief review.

The stack stack is used to store local variables, method parameters, return values, and other temporary values during application execution. The stack is allocated on a per-thread basis and serves as a registers for each thread to complete its work. The garbage collector is not responsible for cleaning up the stack because the stack reserved for method calls is automatically cleaned up when the method returns. Note, however, that the garbage collector knows the references to objects that are stored on the stack. When an object is instantiated in one method, the object's reference (a 32-bit or 64-bit integer value, depending on the platform type) will remain on the stack, while the object itself is stored in the managed heap and collected by the garbage collector when the variable is out of range.

The unmanaged heap is used for run-time data structures, method tables, Microsoft intermediate language (MSIL), jited code, and so on. Unmanaged code assigns it to an unmanaged heap or stack based on the instantiation of the object. Managed code allocates unmanaged heap memory directly by calling an unmanaged WIN32®API or instantiating a COM object. The CLR uses the unmanaged heap extensively for its own data structure and code reasons.

The managed heap managed heap is the area that is used to allocate managed objects and is also the domain of the garbage collector. The CLR uses the generational compression garbage collector. The garbage collector is called a generational, because it divides the objects retained after garbage collection by their lifetime, which helps improve performance. All versions of the. NET Framework are based on three generations of generational methods: the No. 0, 1th, and 2nd generations (from the younger generation to the old generation). The garbage collector is called a compression because it locates the object on the managed heap, thereby eliminating the vulnerability and maintaining the continuity of available memory. Moving large objects is expensive, so the garbage collector assigns these large objects to separate and uncompressed large object heaps. For more information about the managed heap and the garbage collector, see Jeffrey Richter's two-part series "Garbage Collector: automatic memory management in the Microsoft. NET Framework" and "garbage collector-Part 2nd: Microsoft. NE Automatic memory management in the T Framework. Although the writing is based on the. NET Framework 1.0, and the. NET garbage collector has improved, the core idea is consistent with version 1.1 or 2.0.

Detect leaks

There are many indications that a memory leak is occurring in the application. Perhaps the application is triggering outofmemoryexception. Perhaps the application is slow to respond because it initiates the exchange of virtual memory and hard disk. Perhaps the use of memory in Task Manager is gradually rising (and possibly suddenly). When you suspect that the application has a memory leak, you must first determine which type of memory is leaking so that you focus the debugging effort on the appropriate area. Use PerfMon to check the following performance counters for applications: Process/private Bytes,. NET CLR memory/# Bytes in all heaps and. NET CLR locksandthreads/# of CU Rrent logical Threads. The Process/private Bytes counter is used to report all memory that is allocated specifically for a process in the system and cannot be shared with other processes.. NET CLR memory/# Bytes in all Heaps counters report No. 0, 1th, 2nd, and large Object heap Total size.. NET CLR locksandthreads/# of the current logical Threads counter reports the number of logical threads in AppDomain. If the application's logical thread count increases unexpectedly, it indicates that the thread stack has leaked. If the Private Bytes is enlarged and the # Bytes in all heaps remains unchanged, the unmanaged memory leaks. If both of these counters increase, memory consumption in the managed heap is growing.