[Paraview] Memory leaks in Catalyst ?

[Andy Bauer]

Hi Yvan,

I have a merge request into VTK at
https://gitlab.kitware.com/vtk/vtk/merge_requests/3971 that hopefully
improves the memory use. I still have 2 tests that are failing and also
want to test with the ParaView tests so there's a bit more work to do. For
the most part it seems ok though so if you want to try taking those change
and test it on your end I wouldn't mind some extra testing on it,
especially since we're getting so close to the ParaView 5.5 release.

Best,
Andy

On Thu, Feb 22, 2018 at 8:26 PM, Yvan Fournier <yvan.fournier at free.fr>
wrote:

> 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/v
> iewvc/saturne/trunk/src
> /fvm/fvm_to_catalyst.cxx?revision=11048&view=markup
> <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/opensou
> rce/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:
> https://public.kitware.com/mailman/listinfo/paraview
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180224/7d4a345b/attachment.html>