Closed Bug 568761 Opened 11 years ago Closed 11 years ago

WebGL memory leaks


(Core :: Canvas: WebGL, defect)

Not set





(Reporter: bjacob, Assigned: bjacob)




(4 files, 3 obsolete files)

To reproduce, just load this page in Minefield and quit:

Console output:

    => mAllocCount:          25619
    => mReallocCount:         3534
    => mFreeCount:           25556  --  LEAKED 63 !!!
    => mShareCount:          26894
    => mAdoptCount:           2545
    => mAdoptFreeCount:       2543  --  LEAKED 2 !!!

To make sure that this was specific to WebGL, I checked several javascript-heavy sites: no leak.

Valgrind (see attachment) reports no definitive leak but rather blocks that are still reachable at exit. Still a big concern.
Attached file valgrind output
This was obtained using this debugger script (firefox -g -d script):

    valgrind --leak-check=full --show-reachable=yes $*
Attachment #447938 - Attachment mime type: application/octet-stream → text/text
Attachment #447938 - Attachment mime type: text/text → text/plain
OK, looking at these, they don't look WebGL related :)

But why is it then, that Mozilla's console output only reports leaks when I have loaded WebGL pages?
Do you need to have the webgl pref set?

Note that valgrind would not report as leaked static objects with dtors whereas our built-in logging obviously would.
This recently got worse: after playing a few seconds with
I get:

 => mAllocCount:         101513
 => mReallocCount:         4503
 => mFreeCount:           93156  --  LEAKED 8357 !!!
 => mShareCount:          47311
 => mAdoptCount:           3847
 => mAdoptFreeCount:       3844  --  LEAKED 3 !!!
Bah, nevermind my last comment: while trying to answer to comment 3, I disabled webgl and navigate to a few sites, the leak is present everywhere. Seems like we have a big non-webgl-related leak in mozilla-central at the moment.
Have you tried doing a leak log to see what's leaking?
Attached file mochitest output (obsolete) —
The new mochitest (from bug 582053) gives this output at the end. It says we're leaking some WebGLUniformLocation and nsTArray_base objects.
Re: comment 6: I don't know for sure what a "leak log" is, I am just starting to read
Attached file leak log when visiting (obsolete) —
Here's a leak log generating by setting XPCOM_MEM_LEAK_LOG, starting Minefield and navigating to
This is a leak log generated by setting XPCOM_MEM_LEAK_LOG, starting Minefield and navigating to this WebGL test page:

Notice that it has 318 lines, as opposed to the log above which has 317 lines. The additional line is:

 143 WebGLUniformLocation                           56      224       12        4 (    6.90 +/-     3.16)      143        4 (   21.41 +/-    11.44)

In conclusion, we seem to have:
 - a lot of not-WebGL-related leaks
 - at least one WebGL-related leak of WebGLUniformLocation objects
> - a lot of not-WebGL-related leaks

Those look like the sort of output we sometimes get if the you quit the browser while there are network requests in flight.....  If that was not the case, please file a bug.
Depends on: 582252
ok, see bug 582252.
I have reproduced with the default Minefield start page and made sure that it had finished loading (from a naive end-user perspective).
Ok so the non-WebGL leaks (as explained in bug 582252) were specific to my profile, and don't happen with a clean profile.

So here's now the leak log output from the WebGL test mentioned above. Now we can see only 2 classes, WebGLUniformLocation and nsTArray_base.
Attachment #460523 - Attachment is obsolete: true
Attachment #460549 - Attachment is obsolete: true
Attachment #460552 - Attachment is obsolete: true
Aha, here's what Valgrind has to say about this.

The most relevant part seems to be:

==3459== 224 bytes in 4 blocks are definitely lost in loss record 4,468 of 5,447
==3459==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==3459==    by 0x68BD2C3: malloc (nsTraceMalloc.c:1139)
==3459==    by 0x8A97ECD: moz_xmalloc (mozalloc.cpp:98)
==3459==    by 0x59485A4: mozilla::WebGLProgram::GetUniformLocationObject(int) (mozalloc.h:226)
==3459==    by 0x594E181: mozilla::WebGLContext::GetUniformLocation(nsIWebGLProgram*, nsAString_internal const&, nsIWebGLUniformLocation**) (WebGLContextGL.cpp:2075)
==3459==    by 0x61839FE: nsICanvasRenderingContextWebGL_GetUniformLocation(JSContext*, unsigned int, long*) (dom_quickstubs.cpp:27951)
==3459==    by 0x845AA37: js_Interpret (jsops.cpp:2145)
==3459==    by 0x846E659: js_Execute (jsinterp.cpp:891)
==3459==    by 0x83D0975: JS_EvaluateUCScriptForPrincipals (jsapi.cpp:4776)
==3459==    by 0x5B69EA3: nsJSContext::EvaluateString(nsAString_internal const&, void*, nsIPrincipal*, char const*, unsigned int, unsigned int, nsAString_internal*, int*) (nsJSEnvironment.cpp:1794)
==3459==    by 0x58E8CD2: nsScriptLoader::EvaluateScript(nsScriptLoadRequest*, nsString const&) (nsScriptLoader.cpp:764)
==3459==    by 0x58E86A0: nsScriptLoader::ProcessRequest(nsScriptLoadRequest*) (nsScriptLoader.cpp:674)
If we have a refcount leak.. why are we bothering with valgrind.  Just look at the refcount balance tree and see where the missing releases might be?
Then again, simple code inspection indicates that WebGLProgram::GetUniformLocationObject addres the object twice in the cache hit case...
I'm just learning how to use our leak analysis tools and didn't know how to "look at the refcount balance tree" but will make sure to learn...

I agree with your inspection and am looking at this code now! has some docs on using the refcount balancer, if you want.
Attached patch Fix webGL leakSplinter Review
This fixes the leak. I also can't see why I ever wrote this NS_ADDREF.
Attachment #461025 - Flags: review?(vladimir)
(In reply to comment #18)
> has some docs on using
> the refcount balancer, if you want.

Thanks for the link!
You're welcome.  Good to see more people looking into leaks!
Comment on attachment 461025 [details] [diff] [review]
Fix webGL leak

I don't know why I reviewed it!  Nice catch.
Attachment #461025 - Flags: review?(vladimir)
Attachment #461025 - Flags: review+
Attachment #461025 - Flags: approval2.0+
Closed: 11 years ago
Resolution: --- → FIXED
Assignee: nobody → bjacob
You need to log in before you can comment on or make changes to this bug.