MantisBT - ParaView
View Issue Details
0011982ParaViewBugpublic2011-03-17 15:122011-04-25 12:04
Alan Scott 
Robert Maynard 
immediateblockalways
closedfixed 
 
3.10.1 
0011982: 3.10.0 has a fatal memory leak
Kitware knows about this and is actively researching, but I will document it here.

This seems to become a larger problem with clusters. However, it can be replicated on one local server.

* Release, Linux, local server.
* Open up a "top" on your linux machine. It is easier if you only show your own processes - use 'u' within top. Set refresh update to 3 seconds (use 'd').
* Open WhippleShield - 32 file version.
* All variables on. Apply.
* Notice paraview memory footprint.
* Turn all variables off. Apply.
* Notice paraview memory footprint. It has not gotten smaller.
* Turn all variables on. Apply.
* Notice paraview memory footprint. It has grown significantly.
* Memory also seems to grow if we animate.


No tags attached.
related to 0012168closed Robert Maynard Cleanup ResetCache for Exodus reader 
Issue History
2011-03-17 15:12Alan ScottNew Issue
2011-03-17 16:21Utkarsh AyachitAssigned To => David Partyka
2011-03-17 16:21Utkarsh AyachitStatusbacklog => tabled
2011-03-17 16:21Utkarsh AyachitAssigned ToDavid Partyka => Robert Maynard
2011-03-18 13:12Alan ScottNote Added: 0025808
2011-03-18 14:28Robert MaynardNote Added: 0025822
2011-03-18 18:58Alan ScottNote Added: 0025827
2011-04-13 10:29Robert MaynardNote Added: 0026173
2011-04-13 10:29Robert MaynardStatustabled => @80@
2011-04-13 10:29Robert MaynardFixed in Version => 3.10.1
2011-04-13 10:29Robert MaynardResolutionopen => fixed
2011-04-25 12:04Alan ScottNote Added: 0026253
2011-04-25 12:04Alan ScottStatus@80@ => closed
2011-07-21 10:32Ken MorelandRelationship addedrelated to 0012168

Notes
(0025808)
Alan Scott   
2011-03-18 13:12   
Robert,
I poked at this last night, and got totally over my head. A few things I want to mention.
* I opened can.exo up in 3.8.1 as well as 3.10.0, using a debugger. The vtkDataArrayTemplate destructor gets called totally differently now - I wonder if some call to delete memory was removed or forgotten? I did notice that the data seemed to be created the same as it was...
(0025822)
Robert Maynard   
2011-03-18 14:28   
I have currently tracked down an existing memory leak in the ExodusIIReader that doesn't happen in can.exo as it only happens when you have cached geometry. If you use box instead you can replicate the memory leak.

I will also look at vtkDataArrayTemplate.
(0025827)
Alan Scott   
2011-03-18 18:58   
Sounds good.
Be sure to check the bug as listed in the description above with Whipple Shield. That definitely did show it.
(0026173)
Robert Maynard   
2011-04-13 10:29   
I resolved the issue with the following fixes:

Fixed a memory leak in the exodus reader:

author Robert Maynard <robert.maynard@kitware.com>
Fri, 18 Mar 2011 15:24:24 +0000 (11:24 -0400)
committer Robert Maynard <robert.maynard@kitware.com>
Fri, 18 Mar 2011 15:24:24 +0000 (11:24 -0400)
commit d94d7c2a2daf26f0b1a476e7d6ffd264b3629746
tree 6c11386d7f395da70237d21de648f415a5b5561a tree | snapshot
parent 9fda3e707034e45adc261f66089de5d7711d870e commit | diff
Fixed a memory leak in ExodusIIReader.

When stl reserves on a vector with existing objects, it doesn't promise it won't delete and than copy existing objects. This makes sure if that happens we delete the old cached geometery so it doesn't leak.
Hybrid/vtkExodusIIReader.cxx diff | blob | history
Hybrid/vtkExodusIIReaderPrivate.h diff | blob | history

Disabled caching in the exodus reader:

author Robert Maynard <robert.maynard@kitware.com>
Wed, 6 Apr 2011 19:14:15 +0000 (15:14 -0400)
committer David Partyka <david.partyka@kitware.com>
Fri, 8 Apr 2011 21:04:46 +0000 (17:04 -0400)
commit 4f7a24dec2d445ffe13c0fe352ac7511e813d8e7
tree 2784c0f5dc102bdaf6db293661fb028c9451c557 tree | snapshot
parent bb331d4a2cd917f80f61b2fe0d9aec1d34175926 commit | diff
Disable the exodus cache as it was never meant to be enabled.

Change-Id: Ibad6d0086dc57d3c74313b2e01aef05419dc0fae


Reduced the memory foot print of the append data filter:

author Robert Maynard <robert.maynard@kitware.com>
Thu, 31 Mar 2011 17:54:45 +0000 (13:54 -0400)
committer Robert Maynard <robert.maynard@kitware.com>
Thu, 31 Mar 2011 17:54:45 +0000 (13:54 -0400)
commit a6598ca53ab7b3ab0e32144106a298f168ea6150
tree fe940534087d674151a8e4f48506c09f2d809f58 tree | snapshot
parent 67941d51556a27f92b1beb84330e58015d59e11a commit | diff
Append Filter was not squeezing causing it to use more memory than needed.
Graphics/vtkAppendFilter.cxx diff | blob | history

Fixed a bug in vtkView that caused representations to be held onto longer than needed.

author Robert Maynard <robert.maynard@kitware.com>
Fri, 1 Apr 2011 18:00:07 +0000 (14:00 -0400)
committer Robert Maynard <robert.maynard@kitware.com>
Mon, 4 Apr 2011 14:01:01 +0000 (10:01 -0400)
commit 6ca662994dd255caa40f1afcd7561c4d02d48c32
tree 5237dbb1d888480328ee80ebc388135ad3e3ec1b tree | snapshot
parent a6598ca53ab7b3ab0e32144106a298f168ea6150 commit | diff
Removed the implicit connection from a reps input to reps selection.

The view was causing the representation to cache its input, even when
the representation wasn't using its input. Removed the entire methods
as they are not needed.
(0026253)
Alan Scott   
2011-04-25 12:04   
From what we can tell, this is now fixed. Thanks for the extraordinary work.

Tested as listed, redsky.