[Insight-developers] how to attack memory leaks

[Kent Williams]

1. Given the performance penalty of running under valgrind, it may be 
useful to have some memory-checking-specific tests. The existing tests 
of computationally expensive ITK objects are focused on code coverage 
and verifiable results of running the algorithm end-to-end. Tests more 
focused on just getting coverage of all allocation and deallocation, 
without running computationally expensive operations, could yield 
valuable information about leakage without taking all night to run.

2. The Valgrindmassage program I wrote is pretty simple-minded, but cuts 
down on the overwhelming size of valgrind output by removing hex 
addresses of functions in the call stack, and getting rid of specific 
allocation and byte counts that head each leak report. This is most 
useful when processing the valgrind output for several different 
programs -- e.g. all of the different test executables that CTest calls. 
Since each program loads libraries at unique addresses, exactly the same 
memory leak shows up but with slightly different addresses and byte counts.

The output format of valgrind reports is consistent enough that filters 
can be easily written in TCL or Awk or Perl to do similar 
post-processing of valgrind output. This post-processing can do some 
valuable pruning of the forest of error reports, so that you can 
actually see a few trees ;-)

Luis Ibanez wrote:

>
> Kent,
>
> That's great,
>
> Maybe we should put together a ValgridnSuppresion.supp
> file for ITK and maintain it in the CVS repository.
>
> It seems that there are similar files already in CMake and
> VTK but each one is a bit tailored to their own project.
>
> We could start by combining Kent's file from Brains2 and
> the one available in GDCM in Insight/Utilities/gdcm/CMake.
>