[Paraview] Memory leaks in Catalyst ?

Yvan Fournier yvan.fournier at free.fr
Thu Feb 22 20:26:28 EST 2018


Hi Andy,
Thanks for checking.  Fixing my own bug (by adding vtkSmartPointer where needed
in ly adaptor) fixed what seemed the larges issue on a small test case. A
colleague is testing this on a larger case (for a real application) and should
provide me some feedback on a larger, long-running case.
He also observed some artifacts using transparency on a boundary/surface mesh
(not fixed by using -DDEFAULT_SOFTWARE_DEPTH_BITS=31 in Mesa's CFLAGS and
CPPFLAGS, but remind me of issues I had observed on ParaView 5.0 and which had
been fixed in 5.0.1) using llvmpipe. OpenSWR seemed to lead to crashes. I'll
start by testing this on one of my simpler (non-confidential) benchmark cases.
So I'll probably be running a series of additional tests (to update a series
from 2 years ago) and keep you informed if I encounter any issues (and possibly
send a few non-confidential screenshots if everything is working well).
Cheers,
	Yvan
On Thu, 2018-02-22 at 17:33 -0500, Andy Bauer wrote:
> Hi Yvan,
> 
> The vtkPKdTree ones look like they could be after looking at the code,
> especially vtkPKdTree::InitializeRegionAssignmentLists(). It seems like a good
> idea to replace the int **ProcessAssignmentMap with maybe a std::vector.
> Probably a good idea for the other member variables here as well. I'll spend
> some time refactoring vtkPKdTree to make sure that the memory management is
> leak free.
> 
> I don't see anything that suspicious with respect to ParaView in the other
> leak reports, though that doesn't necessarily mean that they aren't leaks.
> 
> Cheers,
> Andy
> 
> On Thu, Feb 22, 2018 at 4:53 PM, Yvan Fournier <yvan.fournier at free.fr> wrote:
> > Hello,
> > 
> > 
> > 
> > Running under Valgrind (memcheck, with --enable-leak-check=full), I have
> > some
> > 
> > warnings about ParaView/Catalyst possibly leaking memory.
> > 
> > 
> > 
> > Catalyst is called from Code_Saturne, whose adapter code (using ParaView
> > Python
> > 
> > adapters from C++) is here https://www.code-saturne.org/viewvc/saturne/trunk
> > /src
> > 
> > /fvm/fvm_to_catalyst.cxx?revision=11048&view=markup, using the attached
> > 
> > results.py script.
> > 
> > 
> > 
> > I fixed a leak in my own code following the Valgrind warnings, but some
> > remining
> > 
> > warnings seem related to calls I have no direct control over, so I attach a
> > log
> > 
> > (on one MPI rank) of Valgrind warnings (edited to remove OpenMPI
> > initialization
> > 
> > related warnings). The first part contains memcheck warnings, the part after
> > 
> > "HEAP SUMMARY" the memory leak info.
> > 
> > 
> > 
> > I'm not sure if the leaks are "one time only" (not too much of an issue), or
> > can
> > 
> > occur at every output timestep (30 in this example, for a small case with
> > about
> > 
> > 8000 mesh elements per MPI rank), so any opinion / checking on that would be
> > 
> > welcome.
> > 
> > 
> > 
> > Best regards,
> > 
> > 
> > 
> >   Yvan Fournier
> > _______________________________________________
> > 
> > Powered by www.kitware.com
> > 
> > 
> > 
> > Visit other Kitware open-source projects at http://www.kitware.com/opensourc
> > e/opensource.html
> > 
> > 
> > 
> > Please keep messages on-topic and check the ParaView Wiki at: http://paravie
> > w.org/Wiki/ParaView
> > 
> > 
> > 
> > Search the list archives at: http://markmail.org/search/?q=ParaView
> > 
> > 
> > 
> > Follow this link to subscribe/unsubscribe:
> > 
> > https://public.kitware.com/mailman/listinfo/paraview
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180223/c2001020/attachment.html>


More information about the ParaView mailing list