Last Comment Bug 651695 - Massive memory leak running CubicVR demo
: Massive memory leak running CubicVR demo
Status: RESOLVED FIXED
[MemShrink:P2]
: mlk, qawanted
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Jeff Muizelaar [:jrmuizel]
:
Mentors:
http://cubicvr.org/CubicVR.js/BeatDet...
Depends on: 638549 655363
Blocks: mlk-fx5
  Show dependency treegraph
 
Reported: 2011-04-20 17:26 PDT by David Humphrey (:humph)
Modified: 2012-01-08 00:49 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Humphrey (:humph) 2011-04-20 17:26:18 PDT
CJ has a new WebGL/Audio demo out, and when playing it in the nightly, my whole machine eventually falls over, with the binary taking 8 gigs of RAM.  I end up with:

11-04-20 7:44:07 PM	kernel	(default pager): [KERNEL]: Switching ON Emergency paging segment
11-04-20 7:45:13 PM	kernel	(default pager): [KERNEL]: System is out of paging space.
11-04-20 7:45:13 PM	kernel	(default pager): [KERNEL]: Failed to recover emergency paging segment
...

The demo plays well for me until 70.379s, at which point the audio effects on the 3D shapes stops working, then it starts doing what looks like GC pauses, then it just collapses.  It doesn't crash, or at least I haven't been able to make it crash yet.
Comment 1 Nicholas Nethercote [:njn] 2011-04-20 18:41:23 PDT
Sound similar to bug 637449.    Benoit, can you take a look?
Comment 2 Benoit Jacob [:bjacob] (mostly away) 2011-04-21 05:23:55 PDT
OK; I will first valgrind the example in bug 637449 comment 21 as it's smaller.

Anyone interested in valgrinding: use OSMesa (set webgl.libosmesa=libOSMesa.so.6 and webgl.force_osmesa=true); procedure and suppression files given on bug 588918.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-04-21 06:39:51 PDT
David: can I get a local copy of this demo?
Comment 4 Charles J. Cliffe 2011-04-21 06:57:12 PDT
Ahoy,

I've added an additional version that uses a simpler non-audio PJS script for the generative texture and removes the audio code from the html: 

http://cubicvr.org/CubicVR.js/BeatDetektor-NMG/index-noaudio.html

And you can grab an offline copy of the whole thing here:

http://cubicvr.org/CubicVR.js/BeatDetektor-NMG/bd-mapgen-test.zip
Comment 5 Benoit Jacob [:bjacob] (mostly away) 2011-04-21 07:09:45 PDT
Thanks. Unfortunately this hits the glGenerateMipmap crash in Mesa, so I'm valgrinding in NVIDIA driver.
Comment 6 Charles J. Cliffe 2011-04-21 07:15:22 PDT
On another note I get weird rendering artifacts on Mac ATI, but more importantly:

http://cubicvr.org/CubicVR.js/BeatDetektor-NMG/index-noaudio-8light.html

This version with one additional light crashes firefox4 release here on my Macbook Pro (10.6) /w Nvidia 320M
Comment 7 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-06-14 14:07:21 PDT
Thanks for the information, Charles. I created bug 664278 based off of your comment.

(In reply to comment #6)
> On another note I get weird rendering artifacts on Mac ATI, but more
> importantly:
> 
> http://cubicvr.org/CubicVR.js/BeatDetektor-NMG/index-noaudio-8light.html
> 
> This version with one additional light crashes firefox4 release here on my
> Macbook Pro (10.6) /w Nvidia 320M
Comment 8 Jeff Muizelaar [:jrmuizel] 2011-06-21 07:07:23 PDT
Can you still reproduce this? I'm able to play both the original and the noaudio demo for a while without any noticeable leak in memory. I'm on a 10.6.7 Mac with ATI hardware. "Real Mem" in activity monitor never goes above 300MB for me.
Comment 9 Jeff Muizelaar [:jrmuizel] 2011-06-21 07:09:53 PDT
Also, does anyone see the leak on platforms other than OS X?
Comment 10 David Humphrey (:humph) 2011-06-25 05:52:58 PDT
(In reply to comment #8)
> Can you still reproduce this? I'm able to play both the original and the
> noaudio demo for a while without any noticeable leak in memory. I'm on a
> 10.6.7 Mac with ATI hardware. "Real Mem" in activity monitor never goes
> above 300MB for me.

Tested on Aurora and Nightly on OS X 10.6, and I can't reproduce this anymore.  Something has been fixed elsewhere for sure.  My memory usage is pretty stable now at ~291M (344M virtual) on Aurora, ~209M (250M virtual) on Nightly.

I also don't have the same rendering artifacts I had previously.  I think this can get closed
Comment 11 Nicholas Nethercote [:njn] 2011-06-25 14:11:46 PDT
It'd be nice to know what fixed this.  David, are you willing to do some bisecting with Nightly builds to try to find out when it was fixed?
Comment 12 Johnny Stenback (:jst, jst@mozilla.com) 2011-06-28 13:17:15 PDT
QA, this needs help with bisecting (unless David's already doing that?).
Comment 13 David Humphrey (:humph) 2011-06-28 14:38:14 PDT
I'm trying, somewhat unsuccessfully, to do some vacation.  I'll be back in action in a few weeks.  If someone in QA could do this in the meantime, that would be great.
Comment 14 Nicholas Nethercote [:njn] 2012-01-08 00:49:37 PST
I can live without the bisecting.  Keeping this bug open isn't helping anyone, so I'll close it.

Note You need to log in before you can comment on or make changes to this bug.