VTK_DEBUG_LEAKS, although will catch some serious errors, will not catch
all kinds of leaks. For example you can have leaks where data
erroneously accumulates with each time step, but is deleted at program
termination. VTK_DEBUG_LEAKS will not catch that kind of error. It's
probably better to use massif to profile your code on a small one node
run. There's an excellent tool called massif visualizer to aid in
exploring the data generated.
$0.02
On 05/20/2016 11:56 AM, Gallagher, Timothy P wrote:
Hi Andy,
Thanks for the tips. I will get working on the VTK_DEBUG_LEAKS now and
see what it turns up.
The initialize/finalize every time is definitely a hack and not for
long-term use. But, sponsors want a report on Monday and we need to be
able to visualize things for that -- the simulation is too big to
write data files and post-process later. So I modified the code to do
that for now until I can find a proper fix.
I'll let you know if I get stuck with the log file.
Thanks again,
Tim
------------------------------------------------------------------------
*From:* Andy Bauer <[email protected]>
*Sent:* Friday, May 20, 2016 2:39 PM
*To:* Gallagher, Timothy P
*Cc:* [email protected]
*Subject:* Re: [Paraview] Memory leak with Catalyst
Hi Tim,
If you build Catalyst with VTK_DEBUG_LEAKS enabled it is pretty good
at finding VTK objects that aren't deleted properly. You should be
able to run this with a small amount of calls to Catalyst as well. If
you try this and want help understanding the output (if an object like
a vtkUnstructuredGrid is leaked it will often give a whole bunch of
false leaks that the unstructured grid is just holding the references
to), just share your output file and I can take a look at it to try
and narrow down the culprit. That may be slightly easier to use than
Valgrind.
Beyond this, you could maybe try the same run but without doing any
Catalyst work to see what happens then. That may be a lot of compute
cycles but I'm not sure how else to try and bisect where the memory
leak is occurring.
Initializing and finalizing Catalyst every time you want output would
probably work but I'd think there may be significant overhead doing it
like this. Plus, it's not really solving the problem -- just avoiding it.
Best,
Andy
On Fri, May 20, 2016 at 12:57 PM, Gallagher, Timothy P
<[email protected] <mailto:[email protected]>> wrote:
Hi,
One of our users is running a very big simulation and writing out
images of two slices (two different views) every 1000 iterations
and writing out the data for the two slices (two different data
writers) as VTK files every 5000 iterations. It is using Paraview
4.4.
After 21000 iterations, the simulation is killed because the
memory on the compute nodes fills up. I usually know how to track
down memory problems in our code using valgrind and related tools,
but is that the right way to go to try and find this problem?
Are there any tips on how to isolate where the problem may be? I
don't know if it is in the adapter, or in paraview itself. Has
anybody encountered problems with runaway memory using Catalyst in
4.4 when writing images or VTK files?
I know when we use pvpython to generate images and loop over many
files, sometimes the memory also blows up and so we usually move
the loop over the files outside the pvpython script and into a
driver script that executes a new pvpython for each file. Is there
a way to shut down/start up Catalyst each time it needs to write
something? Is that advisable?
Thanks,
Tim
_______________________________________________
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
<http://www.kitware.com/opensource/opensource.html>
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView <http://paraview.org/Wiki/ParaView>
Search the list archives at:
http://markmail.org/search/?q=ParaView
<http://markmail.org/search/?q=ParaView>
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
