[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