View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011982 | ParaView | Bug | public | 2011-03-17 15:12 | 2011-04-25 12:04 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Robert Maynard | ||||||||
Priority | immediate | Severity | block | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | 3.10.1 | |||||||
Summary | 0011982: 3.10.0 has a fatal memory leak | ||||||||
Description | 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. | ||||||||
Tags | No tags attached. | ||||||||
Project | |||||||||
Topic Name | |||||||||
Type | |||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |