[Paraview-developers] How to valgrind a paraview plugin ?

houssen houssen at ipgp.fr
Wed Mar 1 05:40:40 EST 2017


How to valgrind a paraview plugin ?

I have a paraview plugin (filter) : I would like to get an MLK analysis 
of it (to know about memory leaks, and more importantly, about invalid 
read / write).

I wrote a as-short-as-possible python script (open_filter.py) that open 
a XDMF file and apply the filter on it. For a try, I started with:
~> valgrind --tool=memcheck --leak-check=yes --show-reachable=yes 
--track-fds=yes --track-origins=yes --log-file=log.out pvbatch 
open_filter.py
pvbatch ends the script in less than 10 seconds, but I get nothing 
relevant (no error) in the log.out because, as you noticed, trace 
children is missing (also tested with --child-silent-after-fork but it 
does not help: same result, no error reported).

Now I add the --trace-children=yes switch to the previous command line 
: this fills log.out but takes more than an hour to run a so small 
fraction (1/8 I would say !?) of the full scenario. Conclusion: this 
seems to work but make the whole thing impossible to use !

I tried without success to play with --trace-children-skip. According 
to valgrind man (--trace-children-skip says it deals with exec), I 
straced the command line delegated to valgrind :
~> strace pvbatch open_filter.py
I get stuffs like :
   execve("/path/to/pvbatch", ["pvbatch", "open_filter.py"], [/* 52 vars 
*/]) = 0
But all shared object (plugins are .so) involved seem to be straced by 
an open (not a exec) :
   open("/lib/x86_64-linux-gnu/libc.so.6")
So my understanding is that it makes --trace-children-skip not doing 
what I expected (not a kernel expert).

Is there a way to valgrind "only plugins" (= a subset of paraview) ?... 
An efficient way !
Are there best pratices on the topic ? Magic command line or switch ? 
Documentation about that ? Any other clue ?

Franck



More information about the Paraview-developers mailing list