Finding Memory Leaks Using the CRT Library

Visual Studio 2010

Other Versions

3 out of 14 rated this helpful - Rate this topic

This topic applies to:

Edition	Visual Basic	C#	F#	C++	Web Developer
Express				Native only
Pro, Premium, and Ultimate				Native only

Memory leaks, defined as the failure to correctly deallocate memory that was previously allocated, are among the most subtle and hard-to-detect bugs in C/C++ applications. A small memory leak might not be noticed at first, but over time, a progressive memory leak can cause symptoms that range from decreased performance to crashing when the application runs out of memory. Worse, a leaking application that uses up all available memory can cause another application to crash, creating confusion as to which application is responsible. Even seemingly harmless memory leaks might be symptomatic of other problems that should be corrected.

The Visual Studio debugger and C Run-Time (CRT) libraries provide you with the means for detecting and identifying memory leaks.

Enabling Memory Leak Detection

---

The primary tools for detecting memory leaks are the debugger and the C Run-Time Libraries (CRT) debug heap functions.

To enable the debug heap functions, include the following statements in your program:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

For the CRT functions to work correctly, the #include statements must follow the order shown here.

Including crtdbg.h maps the malloc and the free functions to their debug versions, _malloc_dbg and free, which track memory allocation and deallocation. This mapping occurs only in debug builds, which have_DEBUG. Release builds use the ordinary malloc and free functions.

The #define statement maps a base version of the CRT heap functions to the corresponding debug version. If you omit the #define statement, the memory leak dump will be less detailed.

After you have enabled the debug heap functions by using these statements, you can place a call to _CrtDumpMemoryLeaks before an application exit point to display a memory-leak report when your application exits:

_CrtDumpMemoryLeaks();

If your application has multiple exits, you do not need to manually place a call to _CrtDumpMemoryLeaks at every exit point. A call to _CrtSetDbgFlag at the beginning of your application will cause an automatic call to _CrtDumpMemoryLeaks at each exit point. You must set the two bit fields shown here:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

By default, _CrtDumpMemoryLeaks outputs the memory-leak report to the Debug pane of the Output window. You can use _CrtSetReportMode to redirect the report to another location.

If you use a library, the library might reset the output to another location. In that case, you can set the output location back to the Output window, as shown here:

_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_DEBUG );

Interpreting the Memory-Leak Report

---

If your application does not define _CRTDBG_MAP_ALLOC, _CrtDumpMemoryLeaks displays a memory-leak report that looks like this:

Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

If your application defines _CRTDBG_MAP_ALLOC, the memory-leak report looks like this:

Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest\leaktest.cpp(20) : {18} 
normal block at 0x00780E80, 64 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

The difference is that the second report shows name of the file and the line number where the leaked memory is first allocated.

Whether you define _CRTDBG_MAP_ALLOC or not, the memory-leak report will display the following information:

• The memory allocation number, which is 18 in this example

• The block type, which is normal in this example.

• The hexadecimal memory location, which is 0x00780E80 in this example.

• The size of the block, 64 bytes in this example.

• The first 16 bytes of data in the block, in hexadecimal form.

The memory-leak report identifies a block of memory as normal, client, or CRT. A normal block is ordinary memory allocated by your program. A client block is a special type of memory block used by MFC programs for objects that require a destructor. The MFC new operator creates either a normal block or a client block, as appropriate for the object being created. A CRT block is allocated by the CRT library for its own use. The CRT library handles the deallocation for these blocks. Therefore, it is unlikely you will see these in the memory leak report unless something is significantly wrong, for example, the CRT library is corrupted.

There are two other types of memory blocks that never appear in memory-leak reports. A free block is memory that has been released. That means it is not leaked, by definition. An ignore block is memory that you have explicitly marked to exclude it from the memory-leak report.

These techniques work for memory allocated using the standard CRT malloc function. If your program allocates memory using the C++ new operator, however, you need to redefine new if you want to see the file and line numbers in the memory-leak report. You can do that with a block of code that looks like this:

#ifdef _DEBUG
   #ifndef DBG_NEW
      #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
      #define new DBG_NEW
   #endif
#endif  // _DEBUG

Setting Breakpoints on a Memory Allocation Number

---

The memory allocation number tells you when a leaked memory block was allocated. A block with a memory allocation number of 18, for example, is the 18th block of memory allocated during the run of the application. The CRT report counts all memory-block allocations during the run. This includes allocations by the CRT library and other libraries such as MFC. Therefore, a block with a memory allocation number of 18 may not be the 18th memory block allocated by your code. Typically, it will not be.

You can use the allocation number to set a breakpoint on the memory allocation.

To set a memory-allocation breakpoint using the Watch window

1. Set a breakpoint near the start of your application, and then start your application.

2. When the application breaks at the breakpoint, the Watch window.

3. In the Watch window, type _crtBreakAlloc in in the Name column.

   If you are using the multithreaded DLL version of the CRT library (the /MD option), include the context operator: {,,msvcr100d.dll}_crtBreakAlloc

4. Press RETURN.

   The debugger evaluates the call and places the result in the Value column. This value will be –1 if you have not set any breakpoints on memory allocations.

5. In the Value column, replace the value shown with the allocation number of the memory allocation where you want to break.

After you set a breakpoint on a memory-allocation number, you can continue to debug. Be careful to run the program under the same conditions as the previous run so that the memory-allocation order does not change. When your program breaks at the specified memory allocation, you can use the Call Stack window and other debugger windows to determine the conditions under which the memory was allocated. Then, you can continue execution to observe what happens to the object and determine why it is not correctly deallocated.

Setting a data breakpoint on the object might also be helpful. For more information, see How to: Set a Data Breakpoint (Native Only).

You can also set memory-allocation breakpoints in code. There are two ways to do this:

_crtBreakAlloc = 18;

or:

_CrtSetBreakAlloc(18);

Comparing Memory States

---

Another technique for locating memory leaks involves taking snapshots of the application's memory state at key points. To take a snapshot of the memory state at a given point in your application, create a_CrtMemState structure and pass it to the _CrtMemCheckpoint function. This function fills in the structure with a snapshot of the current memory state:

_CrtMemState s1;
_CrtMemCheckpoint( &s1 );

_CrtMemCheckpoint fills in the structure with a snapshot of the current memory state.

To output the contents of a _CrtMemState structure, pass the structure to the _ CrtMemDumpStatistics function:

_CrtMemDumpStatistics( &s1 );

_ CrtMemDumpStatistics outputs a dump of memory state that looks like this:

0 bytes in 0 Free Blocks.
0 bytes in 0 Normal Blocks.
3071 bytes in 16 CRT Blocks.
0 bytes in 0 Ignore Blocks.
0 bytes in 0 Client Blocks.
Largest number used: 3071 bytes.
Total allocations: 3764 bytes.

To determine whether a memory leak has occurred in a section of code, you can take snapshots of the memory state before and after the section, and then use _ CrtMemDifference to compare the two states:

_CrtMemCheckpoint( &s1 );
// memory allocations take place here
_CrtMemCheckpoint( &s2 );

if ( _CrtMemDifference( &s3, &s1, &s2) )
   _CrtMemDumpStatistics( &s3 );

_CrtMemDifference compares the memory states s1 and s2 and returns a result in (s3) that is the difference of s1 and s2.

One technique for finding memory leaks begins by placing _CrtMemCheckpoint calls at the beginning and end of your application, then using _CrtMemDifference to compare the results. If _CrtMemDifferenceshows a memory leak, you can add more _CrtMemCheckpoint calls to divide your program using a binary search until you have isolated the source of the leak.

False positives

---

In some cases, _CrtDumpMemoryLeaks can give false indications of memory leaks. This might occur if you use a library that marks internal allocations as _NORMAL_BLOCKs instead of _CRT_BLOCKs or_CLIENT_BLOCKs. In that case, _CrtDumpMemoryLeaks is unable to tell the difference between user allocations and internal library allocations. If the global destructors for the library allocations run after the point where you call _CrtDumpMemoryLeaks, every internal library allocation is reported as a memory leak. Older versions of the Standard Template Library, earlier than Visual Studio .NET, caused_CrtDumpMemoryLeaks to report such false positives, but this has been fixed in recent releases.

See Also

---

Concepts

Debugger Security

Other Resources

The CRT Debug Heap

Debugging Native Code

Detecting Memory Leaks in MFC

Did you find this helpful?  Yes  No

Community Content  Add

  FAQ

setting breakpoint so _crtBreakAlloc works

Setting a breakpoint at the earliest point in our app deosn't work.

We needed to set in crt code as in the blog:
http://rdaemons.blogspot.co.uk/2011/03/visual-c-2010-detecting-memory-leaks.html

C:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src\crt0dat.c
_initterm_e() function

History

• 3/27/2012
• James_UK_DEV

static STL objects still reported as leaks

$0(trying to edit my previous entry just crashes the javascript on the page, so I'm reposting)$0 $0Enter comment here.Contrary to the documentation's assertion that the STL library was fixed, _CrtDumpMemoryLeaks  does continue to report false leaks.  You get false leaks on STL objects if they are declared static: $0 $0 $0static std::string g_myString;$0 $0 $0or part of a class:$0 $0$0 $0

class foo

{

public:

static std::string m_myString;

}

$0 $0$0 $0Both of these lines will report a leak using the _CrtDumpMemoryLeaks functionality.  I've filed a bug for this:$0 $0https://connect.microsoft.com/VisualStudio/feedback/details/697181/crt-memory-leak-detection-routines-still-report-statically-allocated-stl-objects-as-leaks#tabs$0 $0$0 $0$0

History

• 10/29/2011
• mattpf

static STL objects still reported as leaks

Contrary to the documentation's assertion that the STL library was fixed so that   _CrtDumpMemoryLeaks  does not continue to report false leaks; you can still get false leak reports on STL objects if they are declared static: $0static std::string g_myString;$0 $0$0 $0 $0or part of a class$0 $0class foo$0 $0{$0 $0public:$0 $0static std::string m_myString;$0 $0}$0 $0$0 $0 $0Both of these lines will report a leak using the  _CrtDumpMemoryLeaks functionality.  I've filed a bug for this:$0  https://connect.microsoft.com/VisualStudio/feedback/d etails/697181/crt-memory-leak-detection-routines-still-report-statically-allocated-stl-objects-as-leaks#tabs$0

History

• 10/27/2011
• mattpf

{,,msvcr100d.dll_crtBreakAlloc}

In Visual Studio 2010 with toolset set to v100, and with the /MDd, then you will need to use this, instead of the {,,msvcr100d.dll}_crtBreakAlloc like the document mentioned like it in v90 toolset.
http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/544a848b-ccd7-43c0-89be-4bca09f7850e
For the screenshot you can ref my post in this thread.
(int*){,,msvcr100d.dll}__crtBreakAlloc
Two underlines between the "}" and crtBreakAlloc, rather than only one.

History

• 10/18/2011
• Mike Dos Zhang

• 10/18/2011
• Mike Dos Zhang

C++ using NEW operator

When using C++ you need to define _CRTDBG_MAP_ALLOC_NEW in addition to _CRTDBG_MAP_ALLOC in order to get new operators to be registered.

This fixes the file issue where the leaked lines are listed as the memory allocation number and block / memory addresses of the leaked line.

#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW

If you look in <crtdbg.h> 

#if defined(_CRTDBG_MAP_ALLOC) && defined(_CRTDBG_MAP_ALLOC_NEW)
/* We keep these inlines for back compatibility only;
 * the operator new defined in the debug libraries already calls _malloc_dbg,
 * thus enabling the debug heap allocation functionalities.
 *
 * These inlines do not add any information, due that __FILE__ is expanded
 * to "crtdbg.h", which is not very helpful to the user.
 * 
 * The user will need to define _CRTDBG_MAP_ALLOC_NEW in addition to
 * _CRTDBG_MAP_ALLOC to enable these inlines.
 */

You can see this NEW is required to get it working properly for C++ new / delete.

History

• 9/14/2011
• Tyler O

Advertisement