MantisBT - ParaView
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012424ParaView(No Category)public2011-07-28 15:562012-02-08 17:21
ReporterAlan Scott 
Assigned ToUtkarsh Ayachit 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.0Fixed in Version3.14 
ProjectSandia
Topic Name12424_fix_osmesa_leak
Typecrash
Summary0012424: Memory leak in pvbatch using --use-offscreen-rendering
DescriptionI have a user that is having problems with memory leaks in pvbatch, using --use-offscreen-rendering. Here is his excellent writeup:

Summary: ParaView pvbatch: memory leak using --use-offscreen-rendering
Notes: Create Date: 7/27/2011 6:24:05 PM I'm running into an error where the memory footprint of pvbatch keeps growing, despite the data set size remaining the same. This only occurs when using the "--use-offscreen-rendering" option in pvbatch. Unfortunately, I need that option to execute things on redsky, as the job hangs without it.

This bug is present in 3.10.0 and 3.10.1 (Linux 64-bit), but is not present in 3.8.0 or 3.8.1 (Linux 64-bit). I've run this locally and on redsky and got the same results.

My dataset is rather large, but I've reproduced the problem with the following simple script:

--- memory.py ---
from paraview.simple import *
view = CreateRenderView()
view.ViewSize = [700, 400]
source = Sphere(PhiResolution = 1024, ThetaResolution = 1024) display = Show(source)
Render()

loops=20
for i in range(loops):
    print "on iteration %d/%d" % (i, loops)
    source.PhiResolution = 512
    source.ThetaResolution = 512
    Render()
    source.PhiResolution = 1024
    source.ThetaResolution = 1024
    Render()
---

To replicate:
1) run "mpiexec -n 4 pvbatch --use-offscreen-rendering memory.py"
2) notice the memory footprint climbs to about 5 GB at the end of the script

To see desired behavior:
1) run "mpiexec -n 4 pvbatch memory.py"
2) notice memory footprint never grows larger than about 1 GB

If you change the number of loops to 100 or so, it'll eventually crash due to memory.

Thanks,
Tim
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-07-28 15:56Alan ScottNew Issue
2011-08-29 18:00Utkarsh AyachitProduct Version4.0 =>
2011-08-29 18:00Utkarsh AyachitTarget Version => 4.0
2011-12-05 17:54Utkarsh AyachitNote Added: 0027778
2011-12-06 07:33Utkarsh AyachitTopic Name => 12424_fix_osmesa_leak
2011-12-06 07:33Utkarsh AyachitNote Added: 0027779
2011-12-06 07:33Utkarsh AyachitStatusbacklog => gatekeeper review
2011-12-06 07:33Utkarsh AyachitFixed in Version => git-next
2011-12-06 07:33Utkarsh AyachitResolutionopen => fixed
2011-12-06 07:33Utkarsh AyachitAssigned To => Utkarsh Ayachit
2011-12-09 14:20Utkarsh AyachitStatusgatekeeper review => customer review
2011-12-09 14:20Utkarsh AyachitNote Added: 0027788
2011-12-09 14:21Utkarsh AyachitFixed in Versiongit-next => git-master
2011-12-09 15:00Utkarsh AyachitSource_changeset_attached => VTK master b292e29f
2011-12-09 15:00Utkarsh AyachitSource_changeset_attached => VTK master b6ba17e9
2011-12-09 15:00Utkarsh AyachitSource_changeset_attached => VTK master 0f908064
2012-01-24 19:59Alan ScottNote Added: 0027973
2012-01-24 19:59Alan ScottStatuscustomer review => closed
2012-02-08 17:21Utkarsh AyachitFixed in Versiongit-master => 3.14

Notes
(0027778)
Utkarsh Ayachit   
2011-12-05 17:54   
Problem is definitely related to display lists.
If we turn off display lists using the following Python script, the memory does not grow:

# turn off display lists
g = servermanager.misc.GlobalMapperProperties()
g.GlobalImmediateModeRendering = 1
(0027779)
Utkarsh Ayachit   
2011-12-06 07:33   
commit 0f9080648f1086b8abaecbc8bdfdbf9e58e66451
Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Date: Tue Dec 6 07:30:59 2011 -0500

    Fixed BUG 0012424. Display lists were not released correctly.
    
    Display lists were not release correctly when using vtkOSOpenGLRenderWindow.
    vtkOSOpenGLRenderWindow never sets Mapped to 1, consequently the display lists
    were not being cleared. Fixed the logic.
(0027788)
Utkarsh Ayachit   
2011-12-09 14:20   
merged in master (wherever applicable)
(0027973)
Alan Scott   
2012-01-24 19:59   
Not tested.