This technique makes use of a single function call to check for memory leaks. It means that you can quickly and easily add checks for memory leaks to any of your applications.

To add memory leak detection, you just need to add these includes to each source file (if you’re using precompiled headers, you can just place them in the "stdafx.h" header file). Note that the order of inclusion is important.

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

All routines used to allocate memory will now be redefined to store relevant information about the allocation. Now all you need to do, is add the line:

_CrtDumpMemoryLeaks();

at the exit point in your code, which checks to see which areas of memory have not been released. If there are memory leaks, it will notify you in the output window when the program is shut down, and you’ll see something like this:

Detected memory leaks!
Dumping objects ->
C:\PROGRAM FILES\VISUAL STUDIO\MyProjects\leaktest.cpp(120) :
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 
Object dump complete.

You should be able to double click on the line and it will take you to where the leak occurred. However, this isn’t always very helpful (especially if you use C++), as it can take you to an obscure bit of Windows code. To get around this, add this line at the entry point in your program:

_crtBreakAlloc=-1;

(again, you should make sure you add the <crtdbg.h> includes here)

If you find you have a memory leak reported, change -1 to the number reported in the curly brackets (in the above example, 18). This will cause a breakpoint to occur when the memory is allocated, allowing you to find the memory that isn’t being freed. However, keep in mind that this does assume that the same allocation order is being taken each time through the code.

If you don’t want to bother recompiling in order to change "_crtBreakAlloc", just put a break point after the line, and change it manually in the watch window. Alternatively, you could even load it from a text file.

This method will only work for a Debug build, as it #defines itself out of the way of a Release build, so you don’t have to worry about performance issues.

There is a problem however, that you may have spotted. What happens if we have an object that is declared static in a function, which has to deallocate memory in its destructor? Its destructor will be called after your call to "_CrtDumpMemoryLeaks", and there’s nothing you can do about it. Or is there?

Well luckily there is, and you can see how to solve this problem on the next page.

Pages: 1 2