by Marius Bancila

Debugging Tips: Memory Leaks Isolation

In a recent post we showed how to detect memory leaks in MFC. In this post we present some tips for breaking on a particular allocation that leaks. However, you must note that this technique only works if you are able to find a reproducible allocation, with the same number.

Here is a memory leak report:

Detected memory leaks!
Dumping objects ->
{183} normal block at 0x0036B320, 128 bytes long.
 Data:  42 61 62 61 20 53 61 66 74 61 00 CD CD CD CD CD 
Object dump complete.
The program '[1758] MyTest.exe: Native' has exited with code 0 (0x0).

The allocation number is showed in curly brackets {}, and in this case was 183.

The steps to be able to break when an allocation that leaks is created are:

  • Make sure you have the adequate reporting mode for memory leaks (see Finding Memory Leaks Using the CRT Library).
  • Run the program several times until you find reproducible allocation numbers ({183} in the example above) in the memory leaks report at the end of running the program.
  • Put a breakpoint somewhere at the start of the program so you can break as early as possible.
  • Start the application with the debugger.
  • When the initial breakpoint is hit, in the watch window write in the Name column: {,,msvcr90d.dll}_crtBreakAlloc, and in Value column put the allocation number that you want to investigate (in my example it would be 183).
  • Continue debugging (F5).
  • The execution stops at the specified allocation. You can use the Call Stack to navigate back to your code where the allocation was triggered.

Leave a comment