Jean-Philippe Martin | Resources | Memory Checkers Comparison

Memory Checkers

There are some freely available memory checkers. I ran a series of very simple tests to determine what they can do. The wrong series of tests contains code that makes pointer mistakes that are not memory leaks, for example freeing a pointer twice, writing to uninitialized memory or using delete instead of delete []. The leak series of tests contains simple memory leaks, i.e. pointers that are allocated but not released. The ok series of tests contains programs that are correct and thus should not cause the memory checker to output any alarm message.

C tests

Checker	wrong1.c	wrong3.c	wrong6.c	wrong7.c	leak1.c	leak2.c	ok5.c
MALLOC_CHECK_	OK	missed	missed	OK*	missed	missed	OK
dmalloc	OK	missed	missed	OK	OK	OK	OK
memCheckDeluxe	missed	missed	missed	missed	OK	OK	OK
memwatch	OK	missed	missed*	OK	OK	OK	OK
DUMA	OK	missed	missed	OK	OK	OK*	OK
valgrind	OK	OK	missed	OK	OK	OK	OK

C++ tests

Conclusion

memWatch and memCheckDeluxe are both memory leak detectors, and they passed all the memory leak tests. Memwatch wins this round because it was able to detect the double-free in wrong1.c and the out-of-bounds accesses in the dynamically allocated array of wrong7.c (not the static array of wrong6 - but no one else did, either). Both programs are designed to work with C and require a recompilation.

MALLOC_CHECK_ is an interesting test: it is triggered simply by setting the environment variable MALLOC_CHECK_ to 1, and the rest of the magic is done by glibc (see the link in references, below). This is the easiest check to set up and it requires no recompilation. It detected the double free in wrong1 and the mismatched malloc/delete or new/free pairs in wrong2.cc and wrong5.cc. It was able to see that something was fishy in wrong7.c, but it reports a single error at the "free" instead of when we are accessing the memory instead of two errors, for each out-of-bounds access. MALLOC_CHECK_ cannot detect memory leaks and did not detect the use of uninitialized memory in wrong3.

dmalloc is more than a leak detector, but it didn't detect as many bad cases as valgrind and requires a recompile. Also, its C++ support is (in the author's words) minimal. In particular, I have not been able to get dmalloc to report line numbers with C++ (log), although that feature mostly works with C code - in both leak1.c and leak2.c it pointed to the return() instead of the line that allocated the unfreed memory. Dmalloc also often reports unfreed memory, even for programs that are correct. This may be because of errors in the c++ library, but it makes the reports harder to read. In contrast, valgrind has a way to hide leaks that it knows about so its reports are more clear. See also the author's comments.

valgrind is clearly the winner of this little contest. valgrind requires no recompilation of the program, so it's very easy to set up. It identified almost all of the incorrect pointer uses and memory leaks. The only test that it missed is wrong6, in which we break the bounds of an array. No other checker spotted that one, though. Also, valgrind has been improved since we ran this test, so it may perform even better than what we show here.

DUMA is a very close second. The results I am posting here come from Koneru Srikanth (kpsrikanth at gmail dot com) who generously sent them to me. DUMA seems not to require a recompile, but the tests were run on recompiled code. DUMA performs really well. It was also able to detect out-of-bounds writes (it is reported as failing wrong3.cc because it missed the out-of-bounds read). If for some reason valgrind does not work for you, then I recommend that you give DUMA a spin.

Reference

• MALLOC_CHECK_ for glibc (C and C++: requires no recompilation)
• dmalloc-5.2.2 (C, minimal C++ support; requires recompilation)
• memCheckDeluxe-1.2.2 (C, some C++. Requires recompilation)
• memwatch-2.71 (C only; requires recompilation)
• valgrind-1.9.6 (C, C++ and more: requires no recompilation)
• DUMA version 2.4.26 (C and C++. Documentation says that no recompilation is needed, but the tests were run on recompiled code) (as mentioned above, these tests were contributed by Koneru Srikanth).

• electric fence-2.1 (did not compile on first attempt (log))
• Checker-0.9.9.1 (did not compile on first attempt (log); author suggests I use valgrind instead)

• wrong1.c
• wrong3.c
• wrong6.c
• wrong7.c
• leak1.c
• leak2.c
• ok5.c
• wrong1.cc
• wrong2.cc
• wrong3.cc
• wrong4.cc
• wrong5.cc
• wrong6.cc
• leak1.cc
• leak2.cc
• ok5.cc

ToDo

• mpatrol at http://www.cbmamiga.demon.co.uk/mpatrol/

Change History

Please contact me if you have feedback or would like to suggest another tool for the test.