Closed Bug 568761 Opened 11 years ago Closed 11 years ago
GL memory leaks
20.46 KB, text/plain
858 bytes, text/plain
132.89 KB, application/x-xz
992 bytes, patch
|Details | Diff | Splinter Review|
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 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 !!!
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?
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 https://wiki.mozilla.org/Performance:Leak_Tools
Here's a leak log generating by setting XPCOM_MEM_LEAK_LOG, starting Minefield and navigating to google.com.
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
> - 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.
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.
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!
http://www.mozilla.org/performance/leak-tutorial.html has some docs on using the refcount balancer, if you want.
This fixes the leak. I also can't see why I ever wrote this NS_ADDREF.
(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!
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.