[Paraview] Memory leaks in Catalyst ?

Mon Feb 26 13:47:13 EST 2018

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 --------------
A non-text attachment was scrubbed...
Name: vg_r1.log
Type: text/x-log
Size: 151499 bytes
Desc: not available
URL: <https://public.kitware.com/pipermail/paraview/attachments/20180226/8deddb5d/attachment.bin>