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

[Utkarsh Ayachit]

Franck,

To add to what Mathieu said, the executable bin/paraview in an
installed version of ParaView is simply a shared-forwarding executable
that execs the executable lib/paraview-<version>/paraview. If you do
`./bin/paraview --print`, it will show the LD_LIBRARY_PATH values it
sets. You can set those manually and then directly launch the
./lib/paraview-<version>/paraview executable.  Hopefully that will
help clean up the log.

Utkarsh

On Thu, Mar 2, 2017 at 3:46 AM, Mathieu Westphal
<mathieu.westphal at kitware.com> wrote:
> Hi
>
> When valgrinding a plugin, i usually go with the full application. There is
> some valgrind suppression files in
> paraview/CMake/ParaViewValgrindSuppressions.sup
> It can be a bit slow, but in two/three minutes you should be able to run
> ParaView, load and test your plugin.
>
> If your plugin is simple a vtk filter and associated xml, you can also write
> a vtk code using it. Mush smaller in this case.
>
> Regards,
>
> Mathieu Westphal
>
> On Wed, Mar 1, 2017 at 11:40 AM, houssen <houssen at ipgp.fr> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at:
>> http://markmail.org/search/?q=Paraview-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at:
> http://markmail.org/search/?q=Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview-developers
>