+
+Memory checkers are debugging tools that help programmers find
+improper use of pointers, typically memory leaks.
+
+
+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.
+
+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
+
+I tested:
+
+
+
MALLOC_CHECK_
+ for glibc (C and C++: requires no recompilation)
+
dmalloc-5.2.2 (C, minimal C++ support; 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).
+