Visual C++ Debugging: How to manage memory leaks?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums
Results 1 to 1 of 1

Thread: Visual C++ Debugging: How to manage memory leaks?

  1. #1
    Join Date
    Oct 2002
    Timisoara, Romania

    Visual C++ Debugging: How to manage memory leaks?

    Q: What is a memory leak?

    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:

      void foo()
        int *i = new int;
        *i = 44;

        char* str = new char[20];
        strcpy(str,"memory leak");

    • "Lost" pointers

      class Sample
        int* val;
          val = new int;
          *val = 44;
          delete val;
      void foo()
        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[10];
      delete d; // delete d[0]; 
      	  // must use delete [] d;

    • Misplaced delete

      int *i;
        i = new int;
        // some code
      delete i;

    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:

    Detected memory leaks!
    Dumping objects ->
    D:\VisualC++\CodeGuru\MemoryLeak\MemoryLeak.cpp(67) : {60} 
    normal block at 0x00324818, 4 bytes long.
    Data: <,   > 2C 00 00 00 
    Object dump complete.
    If you do not use the '#define _CRTDBG_MAP_ALLOC' statement, defined in 'crtdbg.h', included in 'afx.h', which is by default included in your 'stdafx.h', the memory leak dump would look like this

    Detected memory leaks!
    Dumping objects ->
    {60} normal block at 0x00324818, 4 bytes long.
    Data: <,   > 2C 00 00 00 
    Object dump complete.
    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.

    // DbgNew.h
    // Defines global operator new to allocate from client blocks
    #ifdef _DEBUG
       #define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
       #define DEBUG_CLIENTBLOCK
    // MyApp.cpp
    // Compile options needed: /Zi /D_DEBUG /MLd or use a
    // Default Workspace for a Console Application to build a debug version
    #include <crtdbg.h>
    #include <dbgnew.h>
    #ifdef _DEBUG
    #define new DEBUG_CLIENTBLOCK
    int main( )   
       int* array = new int[10];
       return 0;

    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
    } _CrtMemState;
    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:

    #include <iostream>
    #define _CRTDBG_MAP_ALLOC
    #include <crtdbg.h>
    int main()
       int* array = new int[10];
       return 0;

    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'
    • Object Dumps: 'CMemoryState:: DumpAllObjectsSince'

    Q: Cay you give me an example?

    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.

    #ifdef _DEBUG
       CMemoryState oldMemState, newMemState, diffMemState;
       // Do your memory allocations and deallocations.
       CSite* p = new CSite( "CodeGuru", "");
    #ifdef _DEBUG
       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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Azure Activities Information Page

Windows Mobile Development Center

Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


HTML5 Development Center