Tracking Down Memory Leaks with _afxBreakAlloc

Last reviewed: July 31, 1997
Article ID: Q122307
1.00 1.50 | 1.00 2.00
WINDOWS   | WINDOWS NT
kbprg kbtshoot

The information in this article applies to:

  • The Microsoft Foundation Classes (MFC), included with:

        - Microsoft Visual C++ for Windows, versions 1.0 and 1.5
        - Microsoft Visual C++, 32-bit Edition, versions 1.0 and 2.0
          on the following platform: x86
    

SUMMARY

There is currently no documentation for the _afxBreakAlloc symbol defined by MFC. However it can be extremely useful in finding the cause of memory leaks in an application. This article explains how to use it.

Note: In Visual C++ 32-bit Edition, version 4.0, the method described below is obsolete. For information on diagnosing memory leaks in this version of Visual C++, refer to the Visual C++ 4.0 Books Online topic "Diagnostics: Detecting Memory Leaks" in the "Programming with MFC: Encyclopedia."

MORE INFORMATION

The Microsoft Foundation Classes have memory leak detection capabilities. When you execute a debug build of your application and you have used the AFX Trace Options Tool to Enable Tracing, MFC will report memory leaks when an object has been allocated (using operator new) but not deleted before the application exits. The default output in the debug window will look similar to this:

   MDI16: Detected memory leaks!
   MDI16: Dumping objects ->
   MDI16: {6} str.cpp(82):non-object block at $24D76B72,5 bytes long
   MDI16: {5} non-object block at $24D76B4E, 6 bytes long
   MDI16: Object dump complete.

The number found in the braces ({n}) indicates the allocation number that has occured. In the first object dump, it is obvious where the allocation occured. But the second object dump does not give the file and line number information, so it might be more difficult to track down the leak. However, MFC has the capability of breaking on a particular allocation number by using the _afxBreakAlloc symbol.

The _afxBreakAlloc variable is not available programmatically because it is defined as a static variable in the MFC source code module AFXMEM.CPP. However it can be set/modified using the debugger. We can find the point in our code in which memory allocation number 5 occured by setting _afxBreakAlloc equal to 5 before we get to that point in the code. To do so, follow these steps:

  1. Open the file AFXMEM.CPP (by default it is located in the directory \MSVC20\MFC\SRC\). Find the function AfxAllocMemoryDebug (in VC 1.x the function is named just AllocMemoryDebug). Set a breakpoint on the first line of this function (the opening { ).

  2. Run the program until it breaks at this new breakpoint. Remove the breakpoint.

  3. Open the Watch Window by selecting Window.Watch.

  4. Type in _afxBreakAlloc and press enter. The watch window should now display:

          _afxBreakAlloc = -1
    

  5. Change the -1 to the number of the object leak indicated in the curly braces of the object dump. In this example, change the -1 to a 5.

  6. Continue executing the program by pressing the F5 key.

When the allocation of the object occurs, your program will break in the debugger. You can identify which line of code caused the allocation by looking at the Call Stack (select Debug.Show Call Stack).


Additional reference words: kbinf 1.00 1.50 2.00 2.10 2.50 3.00
KBCategory: kbprg kbtshoot
KBSubcategory: MfcMisc VWBIss CvwIss WBDebug
Keywords : CvwIss MfcMisc VwbIss WBDebug kbprg kbtshoot
Technology : kbMfc
Version : 1.00 1.50 | 1.00 2.00
Platform : NT WINDOWS


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 31, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.