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, <[email protected]> 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" <[email protected]> > À: "Yvan Fournier" <[email protected]> > Cc: "Paraview ([email protected])" <[email protected]> > 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 < [email protected] > > 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 < [email protected] > > 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 > > > >
_______________________________________________ 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
