Closed
Bug 657556
Opened 13 years ago
Closed 13 years ago
crash in WebGL uniform setters when no program is bound (and the uniform object isn't bound to a program either)
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: posidron, Assigned: bjacob)
Details
Attachments
(3 files)
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
Reporter | ||
Comment 1•13 years ago
|
||
Assignee | ||
Comment 2•13 years ago
|
||
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)
OS: Mac OS X → All
Assignee | ||
Comment 3•13 years ago
|
||
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.
Attachment #533274 -
Flags: review?(christoph.diehl)
Assignee | ||
Updated•13 years ago
|
Summary: WebGL crash [@mozilla::CheckedInt<unsigned int>::value] → crash in WebGL uniform setters when no program is bound (and the uniform object isn't bound to a program either)
Assignee | ||
Comment 4•13 years ago
|
||
Note: apparently, the way that the testcase managed to produce a uniform not bound to a program was to delete the program first.
Reporter | ||
Comment 5•13 years ago
|
||
Comment on attachment 533274 [details] [diff] [review] check for null program in OBTAIN_UNIFORM_LOCATION Patch reviewed, applied and tested. Fixed.
Attachment #533274 -
Flags: review?(christoph.diehl) → review+
Assignee | ||
Comment 6•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d22050685463
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•13 years ago
|
||
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.
Updated•13 years ago
|
Assignee: nobody → bjacob
You need to log in
before you can comment on or make changes to this bug.
Description
•