After many years of working on a general-purpose C++ library using the Microsoft MSVC compiler in Visual Studio, we are now porting it to Linux/Mac OS X (pray for us). I hav
You may also find the MALLOC_CHECK_ environment variable useful.
From malloc(3) man page:
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x) include a malloc() implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic message is printed on stderr; if set to 2, abort(3) is called immediately; if set to 3, a diagnostic message is printed on stderr and the program is aborted. Using a non-zero MALLOC_CHECK_ value can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
I'm not aware of anything "built-in" that does what you describe, but it doesn't seem like it would be very hard to "roll your own" version of this. You just want your debugging new to record the pointer, file and line in a map<void*, AllocationInfo>
where the key is the allocated pointer and the value (AllocationInfo
) would be some struct that holds the filename, line number, etc. You also need to define a custom delete operator that checks the map for the pointer being deleted. If found, that entry is removed from the map. Then at process shutdown time you emit the contents of the map.
I found a page where someone describes their own home-grown system that works like this.
I had the same problem when we started porting to the Mac. "Run with performance tool -> Leaks" was the only I found and I'm less than thrilled by it ... at least compared to CRTDEBUG. I understand there are some options (as described by others here), but eventually since we are multi platform, we're using Windows to look for the leaks.
Since you mention the static analyzer. We spent some time trying to figure out hot to get it running until we found that it only does C but not C++
You should have a look at "Cross-Platform Memory Leak Detector", looks very similar to the crtdbg.h technique.
You have a number of options available to you.
First, and most popularly, you can run your application under tools like Valgrind. That should point you to a number of memory abuses, such as NULL pointer reads and writes and memory leaks. There are a number of tools available in the Valgrind suite, so be sure to check them out.
Second, you can always use a library that uses the LD_PRELOAD trick. Basically, the LD_PRELOAD trick allows for DLL injection, which means that tools can be created to help track your memory usage within your application without changing anything. You will find tools such as dmalloc and efence to be quite extensive in the debugging facilities that they offer.
Lastly, recent GCC releases included a tool called Mudflap. This basically uses the function instrumentation to wrap calls around the same memory functions that dmalloc, efence, and Valgrind. The program will be noticably slower, and can be tuned at runtime, though it still looks like it has much potential.
I have used all three and found Valgrind to be very useful. I have been very interested in using Mudflap as well, though I haven't been able to yet.
Maybe you could use the Boehm garbage collector as a leak detection tool:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html
From the site:
#include "leak_detector.h"
main() {
int *p[10];
int i;
/* GC_find_leak = 1; for new collector versions not */
/* compiled with -DFIND_LEAK. */
for (i = 0; i < 10; ++i) {
p[i] = malloc(sizeof(int)+i);
}
for (i = 1; i < 10; ++i) {
free(p[i]);
}
for (i = 0; i < 9; ++i) {
p[i] = malloc(sizeof(int)+i);
}
CHECK_LEAKS();
}
(you get notified via stderr)