How To Tracking Down Memory Leaks with _afxBreakAlloc

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).