A: The failure to properly deallocate memory that was previously allocated.
Q: What are the consequences of memory leaks?
A: Programs that leak large amounts of memory, or leak progressively, may display symptoms ranging from poor (and gradually decreasing) performance to running out of memory completely. Worse, a leaking program may use up so much memory that it causes another program to fail, leaving the user with no clue to where the problem truly lies. In addition, even harmless memory leaks may be symptomatic of other problems.
Q: How can a memory leak appear?
A: There are several causes:
Pointer goes out of scope:
int *i = new int;
*i = 44;
char* str = new char;
val = new int;
*val = 44;
Sample* a = new Sample;
Sample* b = new Sample;
a = b;
delete a; // actually deletes b
//delete b; // already deleted
Wrong usage of new/delete
double* d = new double;
delete d; // delete d;
// must use delete  d;
i = new int;
// some code
Q: How can I find if my program has memory leaks?
A: When you run your program under the debugger, '_CrtDumpMemoryLeaks()' displays memory leak information in the output window. The memory leak information looks like this:
Without '_CRTDBG_MAP_ALLOC' defined, the display shows:
The memory allocation number (inside the curly braces).
The block type (normal, client, or CRT).
The memory location in hexadecimal form.
The size of the block in bytes.
The contents of the first 16 bytes (also in hexadecimal).
With '_CRTDBG_MAP_ALLOC' defined, the display also shows you the file where the leaked memory was allocated. The number in parentheses following the filename (67, in this example) is the line number within the file.
Q: What is the effect of using '_CRTDBG_MAP_ALLOC' on the C++ 'new' and 'delete' operators?
A: When the '_CRTDBG_MAP_ALLOC' flag is defined in the debug version of an application, the base version of the heap functions are directly mapped to their debug versions. This flag is only available when the '_DEBUG' flag has been defined in the application.
The debug versions of the C run-time library contain debug versions of the C++ 'new' and 'delete' operators. If your C++ code defines 'CRTDBG_MAP_ALLOC', all instances of new are mapped to the debug version, which records source file and line number information.
If you want to use the '_CLIENT_BLOCK' allocation type, do not define 'CRTDBG_MAP_ALLOC'. Instead, you must call the Debug version of the 'new' operator directly or create macros that replace the 'new' operator in debug mode, as shown in the following example. The debug version of the 'delete' operator works with all block types and requires no changes in your program when you compile a release version.
// Defines global operator new to allocate from client blocks
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
// Compile options needed: /Zi /D_DEBUG /MLd or use a
// Default Workspace for a Console Application to build a debug version
#define new DEBUG_CLIENTBLOCK
int main( )
int* array = new int;
Q: Are there 'CRT' functions that report the state and content of the heap that can help me to detect memory leaks?
A: In 'crtdbg.h' the following structure is defined:
typedef struct _CrtMemState
struct _CrtMemBlockHeader* pBlockHeader;// Pointer to the most recently allocated block
unsigned long lCounts[_MAX_BLOCKS]; // A counter for each of the 5 types of block
unsigned long lSizes[_MAX_BLOCKS]; // Total bytes allocated in each block type
unsigned long lHighWaterCount; // The most bytes allocated at a time up to now
unsigned long lTotalCount; // The total bytes allocated at present
This structure saves a pointer to the first (most recently allocated) block in the debug heap's linked list. Then, in two arrays, it records how many of each type of memory block ('_NORMAL_BLOCK', '_CLIENT_BLOCK', 'FREE_BLOCK' and so forth) are in the list and the number of bytes allocated in each type of block. Finally, it records the highest number of bytes allocated in the heap as a whole up to that point, and the number of bytes currently allocated.
The following functions report the state and contents of the heap, and use the information to help detect memory leaks and other problems:
'CrtMemCheckpoint' -> Saves a snapshot of the heap in a '_CrtMemState' structure supplied by the application.
'_CrtMemDifference' -> Compares two memory state structures, saves the difference between them in a third state structure, and returns 'TRUE' if the two states are different.
'_CrtMemDumpStatistics' -> Dumps a given '_CrtMemState' structure. The structure may contain a snapshot of the state of the debug heap at a given moment or the difference between two snapshots.
_CrtMemState s1, s2, s3;
_CrtMemCheckpoint( &s1 );
// memory allocations take place here
_CrtMemCheckpoint( &s2 );
if ( _CrtMemDifference( &s3, &s1, &s2) )
_CrtMemDumpStatistics( &s3 );
'_CrtMemDumpAllObjectsSince' -> Dumps information about all objects allocated since a given snapshot was taken of the heap or from the start of execution. Every time it dumps a '_CLIENT_BLOCK' block, it calls a hook function supplied by the application, if one has been installed using '_CrtSetDumpClient'.
'_CrtDumpMemoryLeaks': Determines whether any memory leaks occurred since the start of program execution and, if so, dumps all allocated objects. Every time '_CrtDumpMemoryLeaks' dumps a '_CLIENT_BLOCK' block, it calls a hook function supplied by the application, if one has been installed using '_CrtSetDumpClient'.
Q: How can I dump memory leak information?
A: You can dump memory leak information by including the following statement in your program:
int* array = new int;
Q: How MFC helps me to detect memory leaks?
A: You can make use of:
Tracking Memory Allocations: 'DEBUG_NEW' macro can be used to locate memory leaks
Enabling Memory Diagnostics: enable diagnostic tracing and select specific memory diagnostic features with 'afxMemDF'
Taking Memory Snapshots: snapshots with 'CMemoryState'
Viewing Memory Statistics: 'CMemoryState:: Difference' and 'CMemoryState:: DumpStatistics'
A: This example shows how to take snapshots of memory to help locate a memory leak. Notice that the memory-checking statements are bracketed by #ifdef _DEBUG / #endif blocks so that they are compiled only in Win32 Debug versions of your program.
CMemoryState oldMemState, newMemState, diffMemState;
// Do your memory allocations and deallocations.
CSite* p = new CSite( "CodeGuru", "http://www.codeguru.com");
if( diffMemState.Difference( oldMemState, newMemState ) )
TRACE( "Memory leaked!\n" );
Q: How can I avoid getting memory leaks?
A: Make sure that:
you use correctly 'new'/'delete' and 'new'/'delete' (also 'malloc'/'free')
pointers don't go out of scope before memory is released
if you allocate memory in a loop, you release it in each iteration
Last edited by Andreas Masur; July 25th, 2005 at 01:15 AM.