[Gllug] Memory Leak Detecting

Nix nix at esperi.org.uk
Sun Aug 28 00:38:07 UTC 2005


On Sat, 27 Aug 2005, Peter Childs uttered the following:
>     Does anyone know of any good tools for finding memory leaks other
> than running it through Valgrind multiple times trying to follow as many
> avenues as possible. I'm really lookin for some sort of Parser. As I
> have quite a lot off C++/Qt code I know has leaks and I would really
> love the find and plug them.

Alas, finding memory leaks statically in the general case would require
solving the halting problem (well, actually you collide with Rice's
theorem first, but it's just as deadly). Even doing it unreliably in
most cases is immensely difficult.

Hell, even finding *stack overflows* statically is immensely difficult:
an algorithm is described on page 99 of
<http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf> and even
it is only a heuristic that often gets its answers really rather
wrong. Doing it in the general case also requires solving the halting
problem.

>     Ideas would be most helpful. (Other than proff reading every routine
> line by line. (there is about 200,000 of them in total.

Compiling with -ftest-coverage and using gcov plus valgrind-or-dmalloc
would be a good start: gcov to make sure you've tested most code paths
at least once, valgrind or dmalloc or glibc's built-in memory allocation
debugging to analyze each case. (The latter is probably easiest to use
and certainly far faster than using valgrind: the disadvantage is
principally that valgrind might find other problems too.)


obArgh: two power failures in quick succession. One machine comes up
with a very nasty extra sound added that's either a fan or a disk
dying: the other comes back up with /var completely toasted.

Why does this have to happen on a *Saturday evening* and not a Friday,
so I can't get a new disk for a whole week?

*argh*


(madly running backups)

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list