Created attachment 532884 [details] testcase Environment: OpenGL renderer string: NVIDIA GeForce GT 330M OpenGL Engine OpenGL version string: 2.1 NVIDIA-1.6.26 and OpenGL renderer string: ATI Radeon HD 6750M OpenGL Engine OpenGL version string: 2.1 ATI-1.6.32
Confirmed in linux. Just before the crash, there's a NS_ASSERTION about dereferencing a null refptr. This is surely the real cause of the crash. Running with XPCOM_DEBUG_BREAK=abort to get it to crash, I get this stack: #0 0x00007ffff2bd5165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff2bd7f70 in *__GI_abort () at abort.c:92 #2 0x00007ffff3f0e331 in mozalloc_abort ( msg=0x7fffffff90a0 "###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator->().: 'mRawPtr != 0', file ../../../dist/include/nsAutoPtr.h, line 1117") at /home/bjacob/mozilla-central/memory/mozalloc/mozalloc_abort.cpp:75 #3 0x00007ffff61bc3bf in Abort ( aMsg=0x7fffffff90a0 "###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator->().: 'mRawPtr != 0', file ../../../dist/include/nsAutoPtr.h, line 1117") at /home/bjacob/mozilla-central/xpcom/base/nsDebugImpl.cpp:388 #4 0x00007ffff61bc38d in NS_DebugBreak_P (aSeverity=1, aStr=0x7ffff6b2fe78 "You can't dereference a NULL nsRefPtr with operator->().", aExpr=0x7ffff6b2fe01 "mRawPtr != 0", aFile=0x7ffff6b2fe50 "../../../dist/include/nsAutoPtr.h", aLine=1117) at /home/bjacob/mozilla-central/xpcom/base/nsDebugImpl.cpp:375 #5 0x00007ffff52022b7 in nsRefPtr<mozilla::WebGLProgram>::operator-> (this=0x18f1968) at ../../../dist/include/nsAutoPtr.h:1117 #6 0x00007ffff51e6b53 in mozilla::WebGLContext::Uniform3i (this=0x18f18a0, ploc=0x1c071a0, a1=0, a2=-1, a3=0) at /home/bjacob/mozilla-central/content/canvas/src/WebGLContextGL.cpp:3621 #7 0x00007ffff5a9bc0a in nsIDOMWebGLRenderingContext_Uniform3i (cx=0x1395990, argc=4, vp=0x7fffe29c8208) at /home/bjacob/build/firefox/js/src/xpconnect/src/dom_quickstubs.cpp:33114 #8 0x00007ffff666e4aa in js::CallJSNative (cx=0x1395990, native=0x7ffff5a9ba1e <nsIDOMWebGLRenderingContext_Uniform3i>, argc=4, vp=0x7fffe29c8208) at /home/bjacob/mozilla-central/js/src/jscntxtinlines.h:277 #9 0x00007ffff68447c1 in CallCompiler::generateNativeStub (this=0x7fffffff9e40) at /home/bjacob/mozilla-central/js/src/methodjit/MonoIC.cpp:808 #10 0x00007ffff6840b28 in js::mjit::ic::NativeCall (f=..., ic=0x1c5b8a8)
Created attachment 533274 [details] [diff] [review] check for null program in OBTAIN_UNIFORM_LOCATION The testcase consisted in calling uniform3i() with no bound program object, and on a uniform object that was not bound to a program object. We had this code (in the OBTAIN_UNIFORM_LOCATION macro): if (mCurrentProgram != location_object->Program()) return ErrorInvalidOperation(... This was not enough to check for null mCurrentProgram as the present testcase had location_object->Program() == null. So the fix is add a check specifically for null mCurrentProgram.
Note: apparently, the way that the testcase managed to produce a uniform not bound to a program was to delete the program first.
Comment on attachment 533274 [details] [diff] [review] check for null program in OBTAIN_UNIFORM_LOCATION Patch reviewed, applied and tested. Fixed.
Pushed to Beta: http://hg.mozilla.org/releases/mozilla-beta/rev/eba2dce26189 The fix was already on Aurora, as the Central->Aurora merge happened since I landed on Central.
Ooops --- wrong comment. Sorry, please ignore comment 7.