568761 - WebGL memory leaks

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

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

    http://spidergl.org/example.php?id=1

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.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: valgrind output

This was obtained using this debugger script (firefox -g -d script):

    valgrind --leak-check=full --show-reachable=yes $*

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

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?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

This recently got worse: after playing a few seconds with
http://spidergl.org/example.php?id=9
I get:

 => mAllocCount:         101513
 => mReallocCount:         4503
 => mFreeCount:           93156  --  LEAKED 8357 !!!
 => mShareCount:          47311
 => mAdoptCount:           3847
 => mAdoptFreeCount:       3844  --  LEAKED 3 !!!

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Have you tried doing a leak log to see what's leaking?

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: mochitest output

The new mochitest (from bug 582053) gives this output at the end. It says we're leaking some WebGLUniformLocation and nsTArray_base objects.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

Re: comment 6: I don't know for sure what a "leak log" is, I am just starting to read https://wiki.mozilla.org/Performance:Leak_Tools

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: leak log when visiting google.com

Here's a leak log generating by setting XPCOM_MEM_LEAK_LOG, starting Minefield and navigating to google.com.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: leak log when visiting a particular WebGL test page

This is a leak log generated by setting XPCOM_MEM_LEAK_LOG, starting Minefield and navigating to this WebGL test page:
  https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/gl-uniform-arrays.html

Notice that it has 318 lines, as opposed to the google.com 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

Comment 11

[Boris Zbarsky [:bzbarsky]]

> - 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.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

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).

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: leak log when visiting a particular WebGL test page

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.

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: valgrind log for that WebGL test page

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)

Comment 15

[Boris Zbarsky [:bzbarsky]]

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?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Then again, simple code inspection indicates that WebGLProgram::GetUniformLocationObject addres the object twice in the cache hit case...

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

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!

Comment 18

[Boris Zbarsky [:bzbarsky]]

http://www.mozilla.org/performance/leak-tutorial.html has some docs on using the refcount balancer, if you want.

Comment 19

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Fix webGL leak

This fixes the leak. I also can't see why I ever wrote this NS_ADDREF.

Comment 20

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #18)
> http://www.mozilla.org/performance/leak-tutorial.html has some docs on using
> the refcount balancer, if you want.

Thanks for the link!

Comment 21

[Boris Zbarsky [:bzbarsky]]

You're welcome.  Good to see more people looking into leaks!

Comment 22

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 461025 [details] [diff] [review]
Fix webGL leak

I don't know why I reviewed it!  Nice catch.

Comment 23

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/mozilla-central/rev/9ddb3550723f