View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011982ParaViewBugpublic2011-03-17 15:122011-04-25 12:04
ReporterAlan Scott 
Assigned ToRobert Maynard 
PriorityimmediateSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.10.1 
Summary0011982: 3.10.0 has a fatal memory leak
DescriptionKitware 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.


TagsNo tags attached.
Project
Topic Name
Type
Attached Files

 Relationships
related to 0012168closedRobert Maynard Cleanup ResetCache for Exodus reader 

  Notes
(0025808)
Alan Scott (manager)
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 (developer)
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 (manager)
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 (developer)
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 (manager)
2011-04-25 12:04

 From what we can tell, this is now fixed. Thanks for the extraordinary work.

Tested as listed, redsky.

 Issue History
Date Modified Username Field Change
2011-03-17 15:12 Alan Scott New Issue
2011-03-17 16:21 Utkarsh Ayachit Assigned To => David Partyka
2011-03-17 16:21 Utkarsh Ayachit Status backlog => tabled
2011-03-17 16:21 Utkarsh Ayachit Assigned To David Partyka => Robert Maynard
2011-03-18 13:12 Alan Scott Note Added: 0025808
2011-03-18 14:28 Robert Maynard Note Added: 0025822
2011-03-18 18:58 Alan Scott Note Added: 0025827
2011-04-13 10:29 Robert Maynard Note Added: 0026173
2011-04-13 10:29 Robert Maynard Status tabled => @80@
2011-04-13 10:29 Robert Maynard Fixed in Version => 3.10.1
2011-04-13 10:29 Robert Maynard Resolution open => fixed
2011-04-25 12:04 Alan Scott Note Added: 0026253
2011-04-25 12:04 Alan Scott Status @80@ => closed
2011-07-21 10:32 Ken Moreland Relationship added related to 0012168

Copyright © 2000 - 2018 MantisBT Team