[Paraview] Memory leaks in Catalyst ?

[Andy Bauer]

Thanks for testing and reporting back!

I'll see if I can motivate someone else to look at the other memory leaks
since I'm not as familiar with that code.

FYI: the vtkPKdTree changes are now in VTK master and will likely make it
into PV 5.5.

Best,
Andy

On Mon, Feb 26, 2018 at 1:47 PM, <yvan.fournier at free.fr> wrote:

> Hello Andy,
>
> Here is a log (edited to remove unrelated OpenMPI Valgrind warnings) using
> the patch from your merge request.
>
> It seems the first 2 warnings (related to the kd-tree) have disappeared.
> The rest is unchanged.
>
> I also just ran a test regarding transparency issues a colleague reported.
> I did not reproduce issues running on 224 MPI ranks with a relatively
> simple test case (a tube bundle with only 4 tubes), which is the same test
> case I have been using for some time. So there seem to be issues in more
> complex geometries, but no apparent regression relative to PV 5.0.1). I'll
> need to find a more complex yet non-confidential test case for that issue,
> so I'll keep you updated when I can...
>
> The same user ran 3 days over the week-end (several hundred time steps) on
> that complex mesh, using point sprites, with no crash, so the memory leaks
> don't seem as bad as they used to be (the biggest leak was on my side,
> where the mesh was missing smart pointers...). I haven't seen his images
> yet (reportedly mostly working well but with some transparency parallel
> compositing issues, whether using a transparent boundary or point sprites).
>
> Best regards,
>
>   Yvan
>
>
> ----- Mail original -----
> De: "Andy Bauer" <andy.bauer at kitware.com>
> À: "Yvan Fournier" <yvan.fournier at free.fr>
> Cc: "Paraview (paraview at paraview.org)" <paraview at paraview.org>
> Envoyé: Samedi 24 Février 2018 18:07:17
> Objet: Re: [Paraview] Memory leaks in Catalyst ?
>
>
>
>
>
> 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/
> 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/
> 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:
> https://public.kitware.com/mailman/listinfo/paraview
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180226/b596c63a/attachment.html>