<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-09-01 9:43 GMT+02:00 Elvis Stansvik <span dir="ltr"><<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">2016-09-01 9:31 GMT+02:00 Róbert Špir <span dir="ltr"><<a href="mailto:spir.robert@gmail.com" target="_blank">spir.robert@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="SK"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US">try building vtk with VTK_DEBUG_LEAKS enabled and then you can use vtkDebugLeaks class PrintCurrentLeaks method to print all existing vtk objects. Here you can see whether the object count is increasing or decreasing</span></p></div></div></blockquote><div><br></div></span><div>Ah yes, I'll do that. In the meantime I'm trying to debug with Valgrind Massif, and I have found some strangeness (have to debug further, but there's definitely real leaks going on). Thanks for the tips.<span class=""><font color="#888888"><br><br></font></span></div><span class=""><font color="#888888"><div>Elvis<br> <br></div></font></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="SK"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif"> Elvis Stansvik [mailto:<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplo<wbr>re.com</a>] <br><b>Sent:</b> Thursday, September 1, 2016 9:05 AM<br><b>To:</b> RobertS <<a href="mailto:spir.robert@gmail.com" target="_blank">spir.robert@gmail.com</a>><br><b>Cc:</b> VTK Users <<a href="mailto:vtkusers@vtk.org" target="_blank">vtkusers@vtk.org</a>><br><b>Subject:</b> Re: [vtkusers] Memory not released when volumes are removed<u></u><u></u></span></p><div><div><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal">2016-08-31 17:51 GMT+02:00 Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>><wbr>:<u></u><u></u></p><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p>HI Robert, <u></u><u></u></p><p>Den 31 aug. 2016 5:30 em skrev "Róbert Špir" <<a href="mailto:spir.robert@gmail.com" target="_blank">spir.robert@gmail.com</a>>:<br>><br>> Hi Elvis,<br>><br>> I noticed the same behavior before ( here is the topic <a href="http://vtk.1045678.n5.nabble.com/memory-leak-in-vtkStructuredPoints-or-am-I-doing-something-wrong-tt5738805.html" target="_blank">http://vtk.1045678.n5.nabble.c<wbr>om/memory-leak-in-vtkStructure<wbr>dPoints-or-am-I-doing-<wbr>something-wrong-tt5738805.html</a> )<br>><br>> Looks like it is the standard behavior of Linux (although very weird), since this is not happening in Windows or OS X.<u></u><u></u></p><p>Ah right, now I remember your post. I'll do some more testing to verify that this is actually what's happening in my case, but it likely is.<u></u><u></u></p></blockquote><div><p class="MsoNormal" style="margin-bottom:12pt">I don't think this is the phenomenon I'm seeing. I tried opening the same dataset repeatedly in my app, and I got:<br><br>77 MB<br>368 MB<br>633 MB<br>860 MB<br>1003 MB<br>1171 MB<br>1345 MB<br>1518 MB<br>1691 MB<br>1858 MB<br>2029 MB<br>2201 MB<br>2371 MB<br>2543 MB<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12pt">So the memory usage just keeps growing, despite my attempts to clean up before loading the dataset. This is from the RES (resident) column of top, and I don't think this is memory which can be reclaimed by the OS? That would show up in the VIRT (virtual) column I think.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12pt">So my question remains: Should I do something more to get a thorough cleanup, apart from removing the vtkVolume from the renderer and deleting it (by means of a smart pointer)?</p></div></div></div></div></div></div></div></div></blockquote></div></div></div></div></div></blockquote><div>I found the problem, and it was two silly mistakes by me.<br><br></div><div>The first was plainly visible in the snippet in my first post: I can't use a call to GetNumberOfItems() in the loop condition, since when the vtkVolume is destroyed, the vtkVolumeCollection will observe this and remove the volume from the collection, thus reducing the number of items by one in each iteration. So with my test dataset (3 volumes), only two were destroyed. Saving the result of GetNumberOfItems() before starting the iteration solved that problem.<br><br></div><div>The second mistake was that I was making use of QtConcurrent::mapped to load the volumes in parallel on the Qt thread pool, and then setting up a QFutureWatcher on the resulting QFuture, with a lambda connected to the finished() signal of the QFutureWatcher. In the lambda I set up the visualization parts of the pipeline and added the volumes to the renderer. I was reusing a single QFutureWatcher for this, which would have been fine if it wasn't for the fact that I connect()ed the lambda to its finished() signal each time I loaded a new dataset. So each time the number of connections increased by one, causing the lambda one extra time each time a new dataset was loaded. The solution I opted for was to instead create a new QFutureWatcher each time a data set is loaded, and then also make sure the QFutureWatcher is destroyed when it finishes by connecting finished() to deleteLater().<br><br></div><div>The memory use is no longer growing when I repeatedly load new datasets.<br><br></div><div>Elvis<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="SK"><div><div><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12pt"><u></u><u></u></p></div><div><p class="MsoNormal">Elvis<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p>Thanks,<br>Elvis<u></u><u></u></p><div><div><p>><br>> Best,<br>><br>> Robert<br>><br>>  <br>><br>> From: vtkusers [mailto:<a href="mailto:vtkusers-bounces@vtk.org" target="_blank">vtkusers-bounces@vtk.o<wbr>rg</a>] On Behalf Of Elvis Stansvik<br>> Sent: Wednesday, August 31, 2016 5:19 PM<br>> To: VTK Users <<a href="mailto:vtkusers@vtk.org" target="_blank">vtkusers@vtk.org</a>><br>> Subject: [vtkusers] Memory not released when volumes are removed<br>><br>>  <br>><br>> Hi all,<br>><br>> Before loading a new dataset into our app, I'd like to remove all existing volumes from the renderer, which I believe should lead to them being destroyed as well, since I have no other references to the volumes (currently).<br>><br>> What I tried was<br>><br>>     // Remove all existing volumes<br>>     auto volumes = renderer()->GetVolumes();<br>>     volumes->InitTraversal();<br>>     for (int i = 0; i < volumes->GetNumberOfItems(); ++i) {<br>>         qDebug() << "removing volume";<br>>         vtkSmartPointer<vtkVolume> volume = volumes->GetNextVolume();<br>>         qDebug() << "before:" << volume->GetReferenceCount();<br>>         renderer()->RemoveVolume(volum<wbr>e.GetPointer());<br>>         qDebug() << "after:" << volume->GetReferenceCount();<br>>     }<br>><br>> The output I get each time I load a new dataset (actually the same, but doing it repeatedly) and execution passes by this cleanup code is:<br>><br>> removing volume<br>> before: 3<br>> after: 1<br>> removing volume<br>> before: 3<br>> after: 1<br>> removing volume<br>> before: 3<br>> after: 1<br>><br>> Which sort of makes sense to me: Apparently the renderer holds two references to the volume, since the refcount goes down by 2 when I remove the volume from the renderer. The remaining reference is held by the vtkSmartPointer I created inside the loop.<br>><br>> But, what surprises me is that memory usage does not seem to go down when this code is executed. I would expect that when the scope of the for loop body is exited, the refcount will drop to zero, so the volume should be deleted. And I guess it probably is.<br>><br>> But looking at the memory usage when repeatedly loading datasets (and thus clearing the previous), the resident memory used by the app accumulates.<br>><br>> Must I somehow remove the mapper / underlying image data as well? I'm not holding any references to these, so I would have expected them to die along with the volume.<br>><br>> Helpful for any tips on why this cleanup is apparently not enough to avoid memory accumulation.<br>><br>> Thanks,<br>><br>> Elvis<u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>