How to track memory allocations in C++ (especially new/delete)

How can I track the memory allocations in C++, especially those done by new/delete. For an object, I can easily override the operator new, but I'm not sure how to globally override all allocations so they go through my custom new/delete. This should be not a big problem, but I'm not sure how this is supposed to be done (#define new MY_NEW?).

As soon as this works, I would assume it's enough to have a map somewhere of pointer/location of the allocation, so I can keep track of all allocations which are currently 'active' and - at the end of the application - check for allocations which have not been freed.

Well, this seems again like something that surely has been done several times at least, so any good library out there (preferably a portable one)?

Solution 1:

I would recommend you to use valgrind for linux. It will catch not freed memory, among other bugs like writing to unallocated memory. Another option is mudflap, which tells you about not freed memory too. Use -fmudflap -lmudflap options with gcc, then start your program with MUDFLAP_OPTIONS=-print-leaks ./my_program.

Here's some very simple code. It's not suitable for sophisticated tracking, but intended to show you how you would do it in principle, if you were to implement it yourself. Something like this (left out stuff calling the registered new_handler and other details).

template<typename T>
struct track_alloc : std::allocator<T> {
    typedef typename std::allocator<T>::pointer pointer;
    typedef typename std::allocator<T>::size_type size_type;

    template<typename U>
    struct rebind {
        typedef track_alloc<U> other;
    };

    track_alloc() {}

    template<typename U>
    track_alloc(track_alloc<U> const& u)
        :std::allocator<T>(u) {}

    pointer allocate(size_type size, 
                     std::allocator<void>::const_pointer = 0) {
        void * p = std::malloc(size * sizeof(T));
        if(p == 0) {
            throw std::bad_alloc();
        }
        return static_cast<pointer>(p);
    }

    void deallocate(pointer p, size_type) {
        std::free(p);
    }
};

typedef std::map< void*, std::size_t, std::less<void*>, 
                  track_alloc< std::pair<void* const, std::size_t> > > track_type;

struct track_printer {
    track_type * track;
    track_printer(track_type * track):track(track) {}
    ~track_printer() {
        track_type::const_iterator it = track->begin();
        while(it != track->end()) {
            std::cerr << "TRACK: leaked at " << it->first << ", "
                      << it->second << " bytes\n";
            ++it;
        }
    }
};

track_type * get_map() {
    // don't use normal new to avoid infinite recursion.
    static track_type * track = new (std::malloc(sizeof *track)) 
        track_type;
    static track_printer printer(track);
    return track;
}

void * operator new(std::size_t size) throw(std::bad_alloc) {
    // we are required to return non-null
    void * mem = std::malloc(size == 0 ? 1 : size);
    if(mem == 0) {
        throw std::bad_alloc();
    }
    (*get_map())[mem] = size;
    return mem;
}

void operator delete(void * mem) throw() {
    if(get_map()->erase(mem) == 0) {
        // this indicates a serious bug
        std::cerr << "bug: memory at " 
                  << mem << " wasn't allocated by us\n";
    }
    std::free(mem);
}

int main() {
    std::string *s = new std::string;
        // will print something like: TRACK: leaked at 0x9564008, 4 bytes
}

We have to use our own allocator for our map, because the standard one will use our overridden operator new, which would result in an infinite recursion.

Make sure if you override operator new, you use the map to register your allocations. Deleting memory allocated by placement forms of new will use that delete operator too, so it can become tricky if some code you don't know has overloaded operator new not using your map, because operator delete will tell you that it wasn't allocated and use std::free to free the memory.

Also note, as Pax pointed out for his solution too, this will only show leaks that are caused by code using our own defined operator new/delete. So if you want to use them, put their declaration in a header, and include it in all files that should be watched.

Solution 2:

To be specific, use valgrind's massif tool. As opposed to memcheck, massif is not concerned with illegal use of memory, but tracking allocations over time. It does a good job of 'efficiently' measuring heap memory usage of a program. The best part is, you don't have to write any code. Try:

http://valgrind.org/docs/manual/ms-manual.html

Or if you are really impatient:

valgrind --tool=massif <executable> <args>
ms_print massif.out.<pid> | less

This will give you a graph of allocations over time, and back traces to where the big allocations ocurred. This tool is best run on Linux, I don't know if there is a Windows varient. It does work on OS X.

Good luck!

Solution 3:

You can use the code at http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml with the following modifications: the code as given only works if you have one big honkin' source file. I sorted this out for another question on SO (here).

For a start, don't change stdafx.h, make your modifications in your own files.

Make a separate header file mymemory.h and put your function prototypes in it, for example (note that this has no body):

inline void * __cdecl operator new(unsigned int size,
    const char *file, int line);

Also in that header, put the other prototypes for AddTrack(), DumpUnfreed(), etc., and the #defines, typedef and the extern statement:

extern AllocList *allocList;

Then, in a new mymemory.cpp (which also #include's mymemory.h), put the actual definition of allocList along with all the real functions (not just the prototypes) and add that file to your project.

Then, #include "mymemory.h" in every source file in which you need to track memory (probably all of them). Because there are no definitions in the header file, you won't get duplicates during the link and because the declarations are there, you won't get undefined references either.

Keep in mind that this won't track memory leaks in code that you don't compile (e.g., third-party libraries) but it should let you know about your own problems.

Solution 4:

Well, you can re-implement the global operators new and delete to give you the functionality you want, but I'd advise against that unless this is the only way to track memory allocations, due to restrictions of your platform for example.

Memory debuggers are available for most of the common development platforms. Have a look at PurifyPlus for a commercial solution that works on Windows and various Unixes or valgrind for an open source one that works on Linux (and potentially other operating systems but I've only ever used it on Linux).

If you are intent on replacing the global operators, have a look at this article.