From: Steve Pieper [mailto:pieper@ibility.net]
Sent: August 10, 2013 12:58 AM
To: Andras Lasso
Cc: Ors Petnehazy
Subject: Re: Editor crash due to memory leak

Yes, it must be something like that. If we rule out the editor's undo buffer we can look at other things.

The easiest thing is probably to override the Register and UnRegister virtual methods in vtkImageData and set breakpoints to see where the reference count is being incremented but not decremented.

-Steve

On Fri, Aug 9, 2013 at 6:52 PM, Andras Lasso <lasso@cs.queensu.ca> wrote:
Even with a medium resolution CT as CTChest, each click leaks 72MB.
The compressed labelmap is just 71KB. The CTChest volume size is 145MB uncompressed, 42MB compressed.

Maybe the input volume is saved in the undo buffer as well (because something marks it as modified)?

Andras

From: Steve Pieper [mailto:pieper@ibility.net]
Sent: August 10, 2013 12:39 AM

To: Andras Lasso
Cc: Ors Petnehazy
Subject: Re: Editor crash due to memory leak

No, the undo data is compressed. But there might be something else going on which is why I suggested you test it.

-Steve

On Fri, Aug 9, 2013 at 6:37 PM, Andras Lasso <lasso@cs.queensu.ca> wrote:
If the undoSize controls how many complete, uncompressed copies of the volume is kept in memory, then 100 is definitely too much. Even 10 is quite heavy, but should be OK on most 64-bit systems, if the volume is not too big. Please set the default back to 10 until you make it configurable (or you make the undo buffer more memory-efficient).

thanks
Andras

From: Steve Pieper [mailto:pieper@ibility.net]
Sent: August 10, 2013 12:30 AM
To: Andras Lasso
Cc: Ors Petnehazy
Subject: Re: Editor crash due to memory leak

Hi Andras -

No problem - will look into it. It's probably the undoSize option [1]. It used to be 10 but then I upped it to 100 at the request of some users. You might try changing it if you have a chance. If that turns out to be the issue we should make it configurable.

[1] https://github.com/Slicer/Slicer/blob/master/Modules/Scripted/EditorLib/EditUtil.py#L231

Best,
Steve

undoSize set to 5 => the problem is resolved, total amount of leaks is limited

self.undoRedo.saveState() is commented out => the problem is resolved, no leaks at all

So, the problem seems to be in the undo/redo buffer.

Root cause of the problem found: the image stash compresses the buffer but then the buffer is not squeezed (it left at the default size, which is about the same size as the input uncompressed buffer).

Solution:

Replace these lines in vtkImageStash::Stash()

this->SetStashedScalars(this->GetCompressor()->Compress(p, scalarSize));
this->GetStashedScalars()->Delete(); // reference count already set by Compress

by these:

vtkUnsignedCharArray* compressedBuffer=this->GetCompressor()->Compress(p, scalarSize); // returns a new buffer that has to be deleted
compressedBuffer->Squeeze();
this->SetStashedScalars(compressedBuffer);
compressedBuffer->Delete();

Steve, please review and if you agree then commit.

There is one remaining issue: if the user clicks too quickly then Slicer may run out of memory due to the many stashing going on in processing threads.

I've added a new bug report for this issue: http://www.na-mic.org/Bug/view.php?id=3286

Fix committed in rev 22284 (http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=22284).

Closing resolved issues that have not been updated in more than 3 months