Bug 34656

Summary: i965: Crash when running WebGL Conformance Test in firefox-4 nightly build
Product: Mesa Reporter: Magnus Kessler <Magnus.Kessler>
Component: Drivers/DRI/i965Assignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Magnus Kessler 2011-02-24 02:06:49 UTC 
Firefox crashes in intelFinish() when running the WebGL conformance test.

MOZ_GLX_IGNORE_BLACKLIST=1 gdb firefox https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/uninitialized-test.html


Program received signal SIGSEGV, Segmentation fault.
intelFinish (ctx=<value optimized out>) at intel_context.c:585
585               drm_intel_bo_wait_rendering(irb->region->buffer);
(gdb) bt
#0  intelFinish (ctx=<value optimized out>) at intel_context.c:585
#1  0x00007ffff4f83357 in fFinish (this=0x7fffb5176cd0) at ../../../dist/include/GLContext.h:1305
#2  mozilla::WebGLContext::Finish (this=0x7fffb5176cd0) at WebGLContextGL.cpp:1431
#3  0x00007ffff52e0461 in nsIDOMWebGLRenderingContext_Finish (cx=0x7fffe4c04d60, argc=<value optimized out>, 
    vp=0x7fffe95f20a0) at dom_quickstubs.cpp:29168
#4  0x00007ffff6983216 in CallCompiler::generateNativeStub() () from /usr/lib64/xulrunner-2.0/libmozjs.so
#5  0x00007ffff697e1d3 in js::mjit::ic::NativeCall (f=<value optimized out>, ic=<value optimized out>)
    at methodjit/MonoIC.cpp:1015


(gdb) l
580            struct intel_renderbuffer *irb;
581
582            irb = intel_renderbuffer(fb->_ColorDrawBuffers[i]);
583
584            if (irb && irb->region)
585               drm_intel_bo_wait_rendering(irb->region->buffer);
586        }
587        if (fb->_DepthBuffer) {
588           /* XXX: Wait on buffer idle */
589        }
Comment 1 Chris Wilson 2011-02-24 02:08:18 UTC 
Looks like we hit software rendering, any other errors reported that might be the root cause of that?

/me applies the trivial fixes for the crash.
Comment 2 Chris Wilson 2011-02-24 02:16:01 UTC 
Magnus, if you do find any evidence for how a NULL reached here, then please do file that as a bug. In meantime we will be using swrast.

commit a2029a78c39427f9bd7e24bbe5a5ff124f9d446b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Feb 24 10:12:37 2011 +0000

    intel: Protect against waiting on a NULL render target bo
    
    If we fall back to software rendering due to the render target being
    absent (GPU hang or other error in creating the named target), then we
    do not need to nor should we wait upon the results.
    
    Reported-by: Magnus Kessler <Magnus.Kessler@gmx.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34656
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 3 Magnus Kessler 2011-02-24 02:47:01 UTC 
Unfortunately the fix doesn't seem to work for me. Interestingly, irb isn't actually NULL, but points to some low memory address.

0x00007fffcb48b8c1 in intelFinish (ctx=<value optimized out>) at intel_context.c:584
584            if (irb && irb->region && irb->region->buffer)
(gdb) print irb
$1 = (struct intel_renderbuffer *) 0xd0
Comment 4 Chris Wilson 2011-02-24 03:05:47 UTC 
Hmm, garbage written into the ColorBuffers array. Joy. Any chance of running valgrind?
Comment 5 Eric Anholt 2011-06-07 10:47:53 UTC 
This deletes the code doing the use-after-free.

commit 23b6f9606dc247488835745668b3686218612536
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 31 12:32:06 2011 -0700

    intel: Implement glFinish() correctly by waiting on all previous rendering.
    
    Before, we were waiting for (most of) the current framebuffer to be
    done, which is not quite the same thing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.