Memory Analyzer Tool

This is a discussion on Memory Analyzer Tool within the C Programming forums, part of the General Programming Boards category; I need to have some memory analyzer tool which can detect memory leaks in a program (especially a multithreaded program)... ...

Take a look on zdnet.com for software that adresses memory leaks. You can do a search fo "memory leak" and see what turns up. Be prepared to spend money. I doubt if you will find a very good one for free.

Take a look on zdnet.com for software that adresses memory leaks. You can do a search fo "memory leak" and see what turns up. Be prepared to spend money. I doubt if you will find a very good one for free.

It's not hard to write your own thin layer to check for memory leaks. Whenever you allocate something, store the address and size in an array somewhere. When you deallocate, scan the array and clear the corresponding entry.

At the end of the program, the array will contain each memory block that was leaked.

(Yes, it slows your program down, just like any other good debugging aid.)

Valgrind I believe calls anything not freed() lost memory, which makes valgrind very dumbass in my book. As brewbuck hints at, there are numerous very widely used libraries which do not pointlessly free() memory "at exit" rendering valgrind useless for mem profiling applications which use those libraries.

Not useless. You just need a little creativity.

I use valgrind to check SDL programs for memory leaks, for example. The SDL, however, leaks memory just as you have described. So I wrote a Perl script to remove those lines from the output . . . (note, this script is pretty old, hopefully I'd do a better job if I wrote it now!)

...
STRIP: 368 bytes in 1 blocks are still reachable in loss record 41 of 64
STRIP: 408 bytes in 1 blocks are still reachable in loss record 42 of 64
STRIP: 480 bytes in 4 blocks are still reachable in loss record 43 of 64
STRIP: 624 bytes in 7 blocks are still reachable in loss record 44 of 64
STRIP: 702 bytes in 54 blocks are still reachable in loss record 45 of 64
STRIP: 802 bytes in 88 blocks are still reachable in loss record 46 of 64
==10304==
==10304== 840 bytes in 1 blocks are still reachable in loss record 47 of 64
==10304== at 0x4C216F4: calloc (vg_replace_malloc.c:397)
==10304== by 0x571F62B: _mxml_global (in /usr/lib/libmxml.so.1.4)
==10304== by 0x571BD6A: mxmlSetErrorCallback (in /usr/lib/libmxml.so.1.4)
==10304== by 0x46F410: Callis::Resource::ResourceFile::ResourceFile(std::stri
ng) (ResourceFile.cpp:23)
==10304== by 0x46C178: Callis::Resource::UniverseParserWrapper::UniverseParse
rWrapper(std::string, std::string) (UniverseParser.h:44)
==10304== by 0x468CEA: main (RoleplayMain.cpp:19)
==10304==
STRIP: 880 bytes in 55 blocks are still reachable in loss record 48 of 64
STRIP: 1,024 bytes in 1 blocks are still reachable in loss record 49 of 64
STRIP: 1,092 bytes in 91 blocks are still reachable in loss record 50 of 64
STRIP: 1,117 bytes in 55 blocks are still reachable in loss record 51 of 64
STRIP: 1,341 bytes in 91 blocks are still reachable in loss record 52 of 64
...

which lets me see the memory leaks that are actually my fault.[/off-topic]

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell