<div dir="ltr"><div><div><div>Hi Yvan,<br><br></div>I have a merge request into VTK at <a href="https://gitlab.kitware.com/vtk/vtk/merge_requests/3971">https://gitlab.kitware.com/vtk/vtk/merge_requests/3971</a> 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.<br><br></div>Best,<br></div>Andy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 22, 2018 at 8:26 PM, Yvan Fournier <span dir="ltr"><<a href="mailto:yvan.fournier@free.fr" target="_blank">yvan.fournier@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi Andy,</div><div><br></div><div>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.</div><div><br></div><div>He also observed some artifacts using transparency on a boundary/surface mesh (not fixed by using -DDEFAULT_SOFTWARE_DEPTH_BITS=<wbr>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.</div><div><br></div><div>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).</div><div><br></div><div>Cheers,</div><div><br></div><div> Yvan</div><div><div class="h5"><div><br></div><div>On Thu, 2018-02-22 at 17:33 -0500, Andy Bauer wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Yvan,<br><br></div>The vtkPKdTree ones look like they could be after looking at the code, especially vtkPKdTree::<wbr>InitializeRegionAssignmentList<wbr>s(). 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.<br><br></div>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.<br><br></div>Cheers,<br></div>Andy<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 22, 2018 at 4:53 PM, Yvan Fournier <span dir="ltr"><<a href="mailto:yvan.fournier@free.fr" target="_blank">yvan.fournier@free.fr</a>></span> wrote:<br><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex">Hello,<br>
<br>
Running under Valgrind (memcheck, with --enable-leak-check=full), I have some<br>
warnings about ParaView/Catalyst possibly leaking memory.<br>
<br>
Catalyst is called from Code_Saturne, whose adapter code (using ParaView Python<br>
adapters from C++) is here <a href="https://www.code-saturne.org/viewvc/saturne/trunk/src/fvm/fvm_to_catalyst.cxx?revision=11048&view=markup" rel="noreferrer" target="_blank">https://www.code-saturne.org/v<wbr>iewvc/saturne/trunk/src<br>
/fvm/fvm_to_catalyst.cxx?revis<wbr>ion=11048&view=markup</a>, using the attached<br>
results.py script.<br>
<br>
I fixed a leak in my own code following the Valgrind warnings, but some remining<br>
warnings seem related to calls I have no direct control over, so I attach a log<br>
(on one MPI rank) of Valgrind warnings (edited to remove OpenMPI initialization<br>
related warnings). The first part contains memcheck warnings, the part after<br>
"HEAP SUMMARY" the memory leak info.<br>
<br>
I'm not sure if the leaks are "one time only" (not too much of an issue), or can<br>
occur at every output timestep (30 in this example, for a small case with about<br>
8000 mesh elements per MPI rank), so any opinion / checking on that would be<br>
welcome.<br>
<br>
Best regards,<br>
<br>
Yvan Fournier<br>______________________________<wbr>_________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" rel="noreferrer" target="_blank">http://paraview.org/Wiki/ParaV<wbr>iew</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=ParaView" rel="noreferrer" target="_blank">http://markmail.org/search/?q=<wbr>ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://public.kitware.com/mailman/listinfo/paraview" rel="noreferrer" target="_blank">https://public.kitware.com/mai<wbr>lman/listinfo/paraview</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></blockquote></div><br></div>