View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013841VTK(No Category)public2013-01-31 09:482014-10-01 16:48
ReporterMaarten 
Assigned ToSean McBride 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version5.10.0 
Target VersionFixed in Version6.2.0 
Summary0013841: 2 Snow Leopard Memory Leaks vtkRenderWindowInteractor & vtkRenderWindow
DescriptionSystem:
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;
}
Tagshackaton
ProjectKitware
Typeperformance
Attached Files

 Relationships

  Notes
(0030285)
Sean McBride (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (administrator)
2013-07-22 20:02

 moving all "tabled" bugs into "backlog" category since "tabled" is no longer used.
(0031389)
Sean McBride (developer)
2013-08-05 18:02

 Maarten, can you please try this:

http://review.source.kitware.com/12200 [^]
(0033386)
Sean McBride (developer)
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.

 Issue History
Date Modified Username Field Change
2013-01-31 09:48 Maarten New Issue
2013-01-31 09:59 Sean McBride Note Added: 0030285
2013-01-31 10:14 Maarten Note Added: 0030286
2013-01-31 10:30 Sean McBride Note Added: 0030287
2013-01-31 11:27 Maarten Note Added: 0030288
2013-01-31 13:25 Sean McBride Note Added: 0030289
2013-01-31 13:25 Sean McBride Assigned To => Sean McBride
2013-01-31 13:25 Sean McBride Status backlog => tabled
2013-01-31 17:19 Maarten Note Added: 0030291
2013-07-22 20:02 Dave DeMarle Status tabled => backlog
2013-07-22 20:02 Dave DeMarle Note Added: 0031239
2013-08-05 18:02 Sean McBride Note Added: 0031389
2014-10-01 09:31 Sean McBride Note Added: 0033386
2014-10-01 09:31 Sean McBride Status backlog => tabled
2014-10-01 09:32 Sean McBride Tag Attached: hackaton
2014-10-01 12:40 Berk Geveci Status tabled => backlog
2014-10-01 16:48 Sean McBride Status backlog => closed
2014-10-01 16:48 Sean McBride Resolution open => fixed
2014-10-01 16:48 Sean McBride Fixed in Version => 6.2.0

Copyright © 2000 - 2018 MantisBT Team