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)

x86_64
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: posidron, Assigned: bjacob)

Details

Attachments

(3 files)

Attached file 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
Attached file callstack.txt
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
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)
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)
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.
Attachment #533274 - Flags: review?(christoph.diehl) → review+
http://hg.mozilla.org/mozilla-central/rev/d22050685463
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → 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.
Assignee: nobody → bjacob
You need to log in before you can comment on or make changes to this bug.