MantisBT - VTK
View Issue Details
0013841VTK(No Category)public2013-01-31 09:482014-10-01 16:48
Maarten 
Sean McBride 
normalminorhave not tried
closedfixed 
5.10.0 
6.2.0 
Kitware
performance
0013841: 2 Snow Leopard Memory Leaks vtkRenderWindowInteractor & vtkRenderWindow
System:
2.16 Ghz Intel Core 2 Duo
3GB 667 Mhz
OSX 10.6.8 snow leopard

vtk version 5.10.0


//-----------gives small memory leak (+/- 0.4mb/sec)
int main(int, char *[])
{
      while (true) {
          vtkRenderWindowInteractor *iter = vtkRenderWindowInteractor::New();
          iter->Delete();
      }
    return EXIT_SUCCESS;
}

//-----------gives big memory leak (+/- 50mb/sec)
int main(int, char *[])
{
      while (true) {
          vtkRenderWindow *rw = vtkRenderWindow::New();
          rw->Delete();
      }
    return EXIT_SUCCESS;
}
hackaton
Issue History
2013-01-31 09:48MaartenNew Issue
2013-01-31 09:59Sean McBrideNote Added: 0030285
2013-01-31 10:14MaartenNote Added: 0030286
2013-01-31 10:30Sean McBrideNote Added: 0030287
2013-01-31 11:27MaartenNote Added: 0030288
2013-01-31 13:25Sean McBrideNote Added: 0030289
2013-01-31 13:25Sean McBrideAssigned To => Sean McBride
2013-01-31 13:25Sean McBrideStatusbacklog => tabled
2013-01-31 17:19MaartenNote Added: 0030291
2013-07-22 20:02Dave DeMarleStatustabled => backlog
2013-07-22 20:02Dave DeMarleNote Added: 0031239
2013-08-05 18:02Sean McBrideNote Added: 0031389
2014-10-01 09:31Sean McBrideNote Added: 0033386
2014-10-01 09:31Sean McBrideStatusbacklog => tabled
2014-10-01 09:32Sean McBrideTag Attached: hackaton
2014-10-01 12:40Berk GeveciStatustabled => backlog
2014-10-01 16:48Sean McBrideStatusbacklog => closed
2014-10-01 16:48Sean McBrideResolutionopen => fixed
2014-10-01 16:48Sean McBrideFixed in Version => 6.2.0

Notes
(0030285)
Sean McBride   
2013-01-31 09:59   
How do you conclude there is a leak? Instruments? 'leaks'? valgrind?

You mention 10.6, does the leak occur in 10.7/10.8?
(0030286)
Maarten   
2013-01-31 10:14   
@Sean

I used the OSX native activity monitor.
The physical & virtual memory keeps increasing over time.
I don't have 10.7 and or 10.8 installed, but I can ask a friend with 10.7 installed to test it.
(0030287)
Sean McBride   
2013-01-31 10:30   
Examining physical & virtual memory in Activity Monitor is not a reliable way to detect leaks.

Try a tool like Instrument.app, valgrind, or 'leaks' (see 'man leaks'), they can reliably say if there are leaks or not, and give you the backtrace of where the leaking memory was allocated. Without that kind of info, there's not much to go on here....
(0030288)
Maarten   
2013-01-31 11:27   
Fair enough, as you probably have guessed, I am not familiar with memory tools.

I have used Instruments (leaks) only finding:
(both findings occur only once, so I don't know if it can be considered a serious leak)
16 bytes vtkEarlyCocoaSetup Object leak by dyld library
48 bytes NSAutoReleasePool by Foundation library

Though overall allocations & memory usage keeps increasing over time.

These findings just makes me wonder why iteratively creating and deleting vtkRenderWindows results in increasing memory usage on my system. Shouldn't the memory usage be bounded, instead of growing like mad? Does similar behavior occur on Linux or Windows machines? Or is something missing in my code?
(0030289)
Sean McBride   
2013-01-31 13:25   
I'm not sure what your background knowledge in these matters is, are you familiar with how a modern OS' virtual memory subsystem works?

Anyway, basically the physical and virtual memory columns in Activity Monitor are probably not measuring what you think, and in a way you are better off not looking at them.

You could google these terms to learn more: "RPRVT RSHRD RSIZE VPRVT VSIZE"

Here's a good start:
http://www.mikeash.com/pyblog/friday-qa-2009-06-19-mac-os-x-process-memory-statistics.html [^]
(0030291)
Maarten   
2013-01-31 17:19   
First of all, thanks for the support!

A while back I followed a basic course concerning OS architecture where the basics of virtual memory subsystems were discussed. So I picked up some of the basics. Also, the pointers you gave me helped to put the memory related statistics into perspective.

Let me try to fill you in on my current understanding of the "memory problem" I encounter. I refer to it as "memory problem", since memory leak might not be the right technical term (sorry for that).

1) vtkRenderWindow *rw = vtkRenderWindow::New();

On each cycle of my program an vtkRenderWindow is allocated to memory, the adress to this object in memory is assigned to the variable rw.

2) rw->Delete();

As VTK guidelines prescribe Delete() should be used to properly free the pointed object from memory.

Intuitively (and I am assuming the following, so please correct me if I am wrong) one would expect that by repeating 1 and 2 that at least the RSIZE memory usage should remain around the same level. Now the weird thing is that this doesn't seem to be the case. RPRVT, RSIZE, VPRVT, VSIZE all keep increasing. I tested this by running the program for 15 minutes, until it used up all my RAM and disk space.

As tests with leaks and Instrument.app show me that there isn't any (serious) unreferenced memory allocated (no serious memory leaks), my guess is that "somewhere" some cluttering of data happens.

So concluding: somewhere in my program some cluttering of data happens, and I would like to find out where it happens and what the cause is.

Tomorrow, I want to try to dig a little deeper with Instruments. Do you maybe have any good tools or further suggestions on how to approach this problem?
(0031239)
Dave DeMarle   
2013-07-22 20:02   
moving all "tabled" bugs into "backlog" category since "tabled" is no longer used.
(0031389)
Sean McBride   
2013-08-05 18:02   
Maarten, can you please try this:

http://review.source.kitware.com/12200 [^]
(0033386)
Sean McBride   
2014-10-01 09:31   
Maarten, can you try with VTK git master?

My belief is that either there was never really any leak or it was fixed with the referenced change.