Bug 33545

Summary:	Segfault in glFramebufferTexture2D in i965_dri.so in WebGL test suite
Product:	Mesa	Reporter:	Benoit Jacob <bjacob>
Component:	Drivers/DRI/i965	Assignee:	Ian Romanick <idr>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
URL:	https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/framebuffer-test.html
Whiteboard:
i915 platform:		i915 features:
Attachments:	firefox log copy of the javascript program causing the crash at line 145 copy of the javascript program -- fixed

Description Benoit Jacob 2011-01-26 11:56:48 UTC

Created attachment 42549 [details]
firefox log

I'm forwarding a crash report from a user.

*** Short version: ***

crash in glFramebufferTexture2D in i965_dri.so, in the WebGL test suite.

*** Long version: ***

This crash happens when running the WebGL test suite (see URL field) in firefox 4 nightlies (http://nightly.mozilla.org/).

We have run this in Firefox's "openGL debug mode" where we call glFinish() after every GL call, and log all GL calls, GL error codes, and GL context object pointer, see 'firefox log' attachment.

So we know for sure that there's only one GL context involved here, that there's no GL error, and that the crash actually happened during glFramebufferTexture2D() execution (since we call glFinish() after every GL call).

The firefox stack is not very useful, all it says is we're crashing on first frame into i965_dri.so:

    (gdb) backtrace
    #0  0x00007fffbff99a72 in ?? () from /usr/lib/dri/i965_dri.so
    #1  0x00007ffff4cafc34 in ?? () from ./libxul.so
    #2  0x00007ffff4cd414b in ?? () from ./libxul.so
    #3  0x00007ffff4cd6ec5 in ?? () from ./libxul.so
    #4  0x00007ffff4cc42d0 in ?? () from ./libxul.so
    #5  0x00007ffff55326ca in ?? () from ./libxul.so
    #6  0x00007ffff5f3eb75 in ?? () from ./libxul.so
    #7  0x00007ffff60e61b0 in InjectJaegerReturn () from ./libxul.so
    #8  0x00007ffff60e32e1 in InjectJaegerReturn () from ./libxul.so
    #9  0x00007fffb4853a9a in ?? ()
    #10 0x00007fffb4842000 in ?? ()
    #11 0x0000000000020031 in ?? ()
    #12 0x0000000000000000 in ?? () 

However, we have a useful Javascript stack:

    (gdb) print DumpJSStack()
    0 <TOP LEVEL> ["https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/framebuffer-test.html":145]

I will attach to this bug a copy of the current state of this file so that the line number 145 stays meaningful.


*** System information ***

Ubuntu 10.10 x86-64

$ glxinfo | egrep vendor\|renderer\|version
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100330 DEVELOPMENT 
OpenGL version string: 2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20

Comment 1 Benoit Jacob 2011-01-26 11:59:50 UTC

Created attachment 42550 [details]
copy of the javascript program causing the crash at line 145

The crash occurs at line 145 in this file:

  gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.TEXTURE_2D, null, 0);

The original url (need this to reproduce) is at: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/framebuffer-test.html

Comment 2 Benoit Jacob 2011-01-26 12:05:01 UTC

Created attachment 42551 [details]
copy of the javascript program -- fixed

oops -- previous attachment was bad. look at line 145 in this one.

Comment 3 Eric Anholt 2011-02-04 16:08:11 UTC

Passes for me on Mesa 7.9 and Mesa master when I hit the URL in the bug.

Comment 4 Eric Anholt 2011-06-07 10:48:04 UTC

This should fix the crash in glFinish() I think you were seeing here.

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.

Comment 5 Benoit Jacob 2011-06-07 11:06:19 UTC

Thanks!

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.