Home » C++

Easy memory leak detection in C/C++

30 June 2003 12,680 views 2 Comments

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.

#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:


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


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

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


  • JohnDepther said:

    interesting library ! 5 for the idea
    Does it can catch leaks gdi objects how deleaker for example?

  • AndyN (author) said:

    Hi John,
    Thanks for leaving a comment.

    To be honest, it’s been an age since I wrote this, and I think it’s probably a bit outdated nowadays, what with technology like .NET. Also, since Python is so well integrated into most 3D apps, I find fewer reasons to write C or C++ code anyway.

    As for your question, I’m not sure I understand what you’re asking. Can you clarify?


Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.