I know how to make and sell software online, and I can share my tips with you.
Email | Twitter | LinkedIn | Comics | All articles

Detecting C++ memory leaks

Posted 17 years ago
A while ago I had the problem of detecting memory leaks in my code, and I didn't want to spend lots of money on a brittle software package to do that. It's fairly simple to redefine malloc() and free() to your own functions, to track the file and line number of memory leaks. But what about the new() and delete() operators? It's a little more difficult with C++, if you want to figure out the exact line number of a resource leak.

In this article, I'll explain how you can get a stack trace for where your resource leaks occur. This method is for Microsoft Windows. Linux developers are better served with Valgrind.

Download the source code:

Overview

  • We will use #define to replace the standard implementation of malloc() and free() with ones that record the file and line numbers where they are called. That way, we can track where memory leaks occur for allocations made using the standard C allocation functions.
  • We will overload the new() and delete() operators to track the address of the functions that they are called, by walking backwards up the stack.
  • Finally, we will parse the .map file generated by the linker. This will let us figure out where new() and delete() were called based on the return address information.

The header file

The first thing we'll do is have an #ifdef, because memory tracking is inefficient. You'll want to cut it out in release versions of your code.

debug.h:

#ifdef DEBUG_MEM
#include 
#define malloc(A) _dbgmalloc(__FILE,__LINE, (A) )
#define free(A) _dbgfree( __FILE__, __LINE__, (A) )
// ... continue with calloc, realloc, strdup, etc.
#endif

Every *.cpp source file in your program should include this file. It's optional, of course. But if you allocate something in a memory-tracked module, and free it in another that doesn't, your program will crash, since it was allocated with _dbgmalloc() and free'd with free() instead of _dbgfree().

The implementation for malloc

void*
_dbgmalloc( const char* file, int line, size_t size )
{
    void* ptr;

    if ( !_init ) {
        return malloc( size );
    }

    ptr = add_record( file, line, size );
    if ( ptr == 0 ) {
        dbgprint(( DMEMORY, "Out of memory." ));
        return 0;
    }

    dbgprint(( DMEMORY, "%s:%d: malloc( %d ) [%p]", file, line, size, ptr ));

    return ptr;
}

void _dbgfree( const char* file, int line, void* ptr )
{
    if ( ptr == 0 ) {
        return;
    }

    if ( !_init ) {
        free( ptr );
        return;
    }

    MemBlock* block = (MemBlock*)ptr - 1;
    int size = block->size;

    del_record( file, line, ptr );

    dbgprint(( DMEMORY, "%s:%d: free( [%p], %d )", file, line, ptr, size ));
}

The add_record() and del_record() functions perform the real work of memory tracking. They will allocate the requested amount of memory, but they will add space for extra tracking information. The tracking information is stored in the first few bytes of the memory block, and then the returned pointer offset by this amount. We will also reserve extra space at the end of the memory block, so we will be able to detect writes past the end of the array. We will write a specific sequence of bytes (Here, 0x12345678) at this location, and if when the block is free'd, the bytes have been modified, then your program has done something it shouldn't have, and the del_record() function will complain.

void*
add_record( const char* file, int line, size_t size )
{
    MemBlock* block;
    assert(_init);

    block = (MemBlock*)malloc( sizeof( MemBlock ) + size + 4 );

    if ( block == 0 ) {
        dbgprint(( DMEMORY, "Out of memory." ));
        return 0;
    }

    block->sentry = SENTRY;
    block->size = size;
    block->line = line;
    block->file = _strdup( file );
    if ( 0 == block->file && file ) {
        free( block );
        dbgprint(( DMEMORY, "Out of memory." ));
        return 0;
    }

    memcpy( (char*)block + sizeof(*block) + size, &SENTRY, 
        sizeof( SENTRY ) );

    EnterCriticalSection(&_cs);
    list_add_tail( &_blockList, &block->list );
    LeaveCriticalSection(&_cs);

    return block + 1;
}

What about new?

That's all fine and good for malloc() and free(), and strdup() and _tcsdup() and calloc() and realloc(), but what about C++? When you call malloc() above, you see that the macro puts in the file and line number information, but this is not possible for the new operator. Instead, we will do it the hard way. We'll redefine the new operator and then search up the stack for the caller's address and store that. Later, we'll parse the linker's map file to figure out which function it was from the address.

Here's the implementation for new() and delete(). They are almost the same as malloc() and free() above, except that they record the return address instead of the file and line information.

void* operator new( size_t size ) throw ( std::bad_alloc )
{
    static bool recurse = false;
    void* ret;
    CrashPosition_t pos;
    if ( recurse || !_init) {
        return malloc( size );
    }

    EnterCriticalSection(&_cs);
    pos = getFileLine(1);
    if ( pos.file == 0 ) {
        pos.file = pos.function;
    }

    ret = add_record( pos.file, pos.line, size );
    if ( ret == 0 ) {
        dbgprint(( DMEMORY, "Out of memory." ));
	    LeaveCriticalSection(&_cs);
        return 0;
    }

    dbgprint(( DMEMORY, "%s:%d: new( %d ) [%p]", pos.file, pos.line, size, ret ));
	    LeaveCriticalSection(&_cs);
    return ret;
}


/******************************************************************************
 *****************************************************************************/
void operator delete( void* ptr ) throw ()
{
    CrashPosition_t pos;
    
    if ( !_init ) {
        free( ptr );
        return;
    }

    if ( ptr == 0 ) {
        return;
    }
    EnterCriticalSection(&_cs);

    pos = getFileLine(2);
	    LeaveCriticalSection(&_cs);

    dbgprint(( DMEMORY, "%s:%d: delete [%p]", pos.file, pos.line, ptr ));
    del_record( pos.file, pos.line, ptr );
}

Walking the stack

Here's where the magic happens. Because file and line number information is not available to the new operator, we will walk the stack in order to record the return address. Later on, we'll figure out the function name where they were called from.
static int 
GetCallStack( unsigned* stack, int max )
{
    unsigned* my_ebp = 0;
    int i;

    __asm {
        mov eax, ebp
        mov dword ptr [my_ebp], eax;
    }

    // It is not safe to use this function in a WIN32 standard exception handler!
    if ( IsBadReadPtr( my_ebp + 1, 4 ) ) {
        return 0;
    }

    stack[0] = *(my_ebp + 1);
    for ( i = 1; i < max; i++ ) {
        unsigned addr;
        if ( IsBadReadPtr( my_ebp, 4 ) ) {
            break;
        }
        my_ebp = (unsigned*)(*my_ebp);

        if ( IsBadReadPtr( my_ebp + 1, 4 ) ) {
            break;
        }

        addr = *(my_ebp + 1);
        if ( addr ) {
            stack[i] = addr;
        } else {
			break;
		}
    }

    return i;
}

Making the map file

So far, for malloc() and free() calls, we have recorded the file and line number information, but for new() and delete() we have only the return address. How do we figure out which function called new() and delete()?

We will induce the linker to create a .map file. Add these options to your makefile when calling link.exe. Replace example with the name of your executable output file. (The debug.cpp code will assume that the map file has the same base name as the executable).

/MAP:example.map /MAPINFO:LINES

Compiler differences

Note: For Microsoft Visual Studio 2005, Microsoft has removed the MAPINFO:LINES option. So you should either use an earlier version of the compiler, or be content without line numbers. You will still have function names.

The Map File

The Map file contains a list of every function in your program, and the exact addresses to which they are loaded. So, using a binary search, we are able to look up a function given an address. I have implemented this process in Mapfile.cpp, which is called diretly from debug.cpp.

Putting it together

When your program exits, the debug.cpp module will automatically execute this cleanup code. The cleanup code will dump out any unfree'd memory chunks.
static void
dump_blocks()
{
    list_entry_t* entry = list_head( &_blockList );
    while( entry != &_blockList ) {
        MemBlock* block = list_entry( entry, MemBlock, list );
        dbgprint(( DMEMLEAK, "Leaked %d bytes from %s:%d [%08x]",
                    block->size, block->file, block->line, block + 1
                 ));
        
        entry = entry->next;
    }

    if ( list_empty(&_blockList ) ) {
        dbgprint(( DMEMLEAK, "No memory leaks detected." ));
    }
}

dbgprintf

To see the memory leaks, you will have to implement a debug message handler. I don't have time to explain this right now, but it should be pretty obvious from the source code. Or, you can replace dbgprint() with OutputDebugString(), or printf(), or MessageBox(), or whatever you want.

Enjoy!

Steve Hanov makes a living working on Rhymebrain.com, rapt.ink, www.websequencediagrams.com, and Zwibbler.com. He lives in Waterloo, Canada.
Post comment
Your Email (Not displayed): Post comment
Notice: Any comment containing "http(s):" will be entirely discarded.

Real Name

Editing Password (Optional):

Choose an edit password if you want to be able to edit or delete your comment later.
edit
Ory
eleven years ago
Well, when working on Windows anyway, then I can recommend the "Visual Leak Detector": it's free, works great under Visual Studio, and does provide a stack trace to where the memory leaked was allocated. All that in a format VS understand, so when running a debug build from within VS, double-clicking on the stack traces will actually take you to the code location...
edit
Jojn Depth
13 years ago
I usually use the deleaker in such cases......
edit
MastAvalons
13 years ago
In such cases I use deleaker. And in general - do not allow leaks during the creation of algorithm.
edit
Marc Lepage
14 years ago
These are important skills as noted. You can find a lot of similar tricks noted in places like Dr. Dobbs Journal.

Another good way to avoid memory leaks is to rely more upon the RAII idiom for managing resources using objects. For example, using smart pointers.

edit
Vasya2
14 years ago
To avoid memory leaks just use Deleaker
edit
Peter
14 years ago
MSVC has a very similar built-in function, which records the file name and line number via __FILE__ and __LINE__ macros:

hxxp://msdn.microsoft.com/en-us/library/e5ewb1h3(VS.80).aspx

(change hxxp to http)

Debug heap functions in MSVC can also detect buffer overrun (google for _CrtSetDbgFlag).

edit
elnyka
16 years ago
Dude, I wish I've had that 8 years ago. Cool stuff :)
edit
Jörg
16 years ago
It's a very nice article.

I'm trying to find a hidden memory leak and I'm using your code.

It's very helpful.

Thanks a lot.

edit
Steve Hanov
16 years ago
Hi, John!

The library is designed to be stripped out of DEBUG and DEBUG_MEM are not defined. In order to use it, you have to make sure DEBUG and DEBUG_MEM are defined.

edit
Neo Law
16 years ago
I am using it now. I'll get back and tell you if it works or not. Anyway, thanks.
edit
John
16 years ago
I am trying to find a hidden memory leak and I liked your methodology and your code.

But, my linker is spitting out undefined references to dbgSetHandler and dbgSetKeys.

Any ideas on what could be the problem?

Thanks.

edit
Ming
17 years ago
Ignore Ulysses... It's much better to have the callstack available at runtime. Ulysses should feel fortunate that he hasn't had to debug anyone's code where it was necessary to have a little tool like this.
edit
Fernando
17 years ago
Steve, I tried compliling the files on my application, which is compiled in Unicode, and your files are erroring because the mix of TCHAR, PTSTR, char and so on...

Do you have any updated code?

Anyway excelent tool.

edit
Steve Hanov
17 years ago
Ulysses,

There is an advantage to having memory leak tracking built-in, instead of generating a huge log file with a separate tool. Whenever the debug version of my program exits, it performs the heap check, so I instantly know when and where a memory leak occurs during development. The MS UMDH tool is meant to be run when you suspect there is a problem, not all the time.

Reinvention is an important part of being a good programmer. When someone re-writes an existing software tool, the result is a tool that is a perfect fit for the purpose, plus new skills for the developer. Depending on the scope of the task, there may be a time savings over having to learn the existing tool and working around its bugs.

edit
Ulysses
17 years ago
Reinventing free dump heap and heap compare tools from MS?
edit
Aun
17 years ago
Can this be used with VS 2005 ?
edit
Alice
17 years ago
You know what helps you to detect C++ memory leaks? A new scarf that I knitted.

Four ways of handling asynchronous operations in node.js

Javascript was not designed to do asynchronous operations easily. If it were, then writing asynchronous code would be as easy as writing blocking code. Instead, developers in node.js need to manage many levels of callbacks. Today, we will examine four different methods of performing the same task asynchronously, in node.js.

5 Ways PowToon Made Me Want to Buy Their Software

Even though I saw through their tricks at every step along the way, I am now a customer and proud of it. It is worthwhile to look at what they did, because these are simple things that you can do to improve your software business.

Using the Acer Aspire One as a web server

A netbook can be ideal for a home web server. They are cheap, and use less power than a CFL light bulb.

Experiments in making money online

Is it possible to make money on the internet, if you try really hard? I want to find out. I have always been interested in getting money for doing nothing.

The simple and obvious way to walk through a graph

At some point in your programming career you may have to go through a graph of items and process them all exactly once. If you keep following neighbours, the path might loop back on itself, so you need to keep track of which ones have been processed already.

Comment spam defeated at last

For years when running this blog, I would have to log in each day and delete a dozen comments due to spam. This was a chore, and I tried many ways to stem the tide.

Email Etiquette

If you begin your emails with "Hi, <name>!" then they will seem less rude.

An instant rhyming dictionary for any web site

Sometimes your API has to be simple enough for non-technical people to use it. Find out how to include a rhyming dictionary on your web page just by copying and pasting.

Keeping Abreast of Pornographic Research in Computer Science

Burgeoning numbers of Ph.D's and grad students are choosing to study pornography. Techniques for the analysis of "objectionable images" are gaining increased attention (and grant money) from governments and research institutions around the world, as well as Google. But what, exactly, does computer science have to do with porn? In the name of academic persuit, let's roll up our sleeves and plunge deeply into this often hidden area that lies between the covers of top-shelf research journals.

Installing the Latest Debian on an Ancient Laptop

The challenge: Install Linux on a really old laptop. The catch: It has only 32 MB of RAM, no network ports, no CD-ROM, and the floppy drive makes creaking noises. Is it possible? Yes. Is it easy? No. Is is useful? Maybe...