BadDrawable crash when doing any OpenGL stuff with software Mesa

The HTML5 test located at http://www.html5test.com crashes the browser if the preference webgl.enabled_for_all_sites is true.

Crash report:

bp-2fb4119c-d22d-4c85-a23d-1b1292100822

I only see this under Linux. I should also mention that I am using osmesalib as my graphics driver does not support opengl.

Here on linux / x86-64 with OSMesa, I can't reproduce the crash (and the test reports all green about WebGL).

This is a really strange crash, since the crash location is in the VDSO, linux-gate.so, and the backtrace leading to the crash only mentions libc.

Is there any reason why you think it's a WebGL-related crash, besides that it crashed while running a WebGL demo?

Another linux-gate.so crash was fixed not long ago: bug 519601.

Here's an interesting read on the VDSO:
    http://www.trilithium.com/johan/2005/08/linux-gate/

By the way, as far as WebGL is concerned, this html5test is broken, as all it tries to do is create a WebGL context. It would be very easy for a browser not supporting WebGL to fake it for this test, with about 20 lines of c++ code.

Adding Karl and Chris in CC: since they worked on the other linux-gate.so crash, bug 519601, they might have an idea about this one...

(In reply to comment #2)
> Is there any reason why you think it's a WebGL-related crash, besides that it
> crashed while running a WebGL demo?

Just because toggling the webgl.enabled_for_all_sites preference avoids the crash.

(In reply to comment #2)
> This is a really strange crash, since the crash location is in the VDSO,
> linux-gate.so, and the backtrace leading to the crash only mentions libc.

Not e that in the APP notes, it says "X_CreateGC: BadDrawable (invalid Pixmap or Window parameter); 3 requests ago".

i think more or less what you're seeing is libc calling abort, and abort being a kernel function which kills the process:
Crash Reason SIGABRT

roughly linux-gate is entirely uninteresting. *all* kernel functions go through it.

@ timeless: ah, so basically, it is crashing on an assertion failure in libc. Thanks for the explanation.

@ Bill: interesting! Something you could do is install debug symbols ("debug info") packages for all the libraries mentioned in the "raw dump" tab of the crash report (starting with libc) and reproduce the crash so we hopefully get more information...

(In reply to comment #7)
> @ Bill: interesting! Something you could do is install debug symbols ("debug
> info") packages for all the libraries mentioned in the "raw dump" tab of the
> crash report (starting with libc) and reproduce the crash so we hopefully get
> more information...

That is easier said than done. Unfortunately, you get install conflicts if you try to install 32-bit and 64-bit debug symbols for the same library. I will try uninstalling the 64-bit glibc-debuginfo and installing the 32-bit one and generate a new crash to see if that shows anything further.

OH. It also seems it is trying to use the driver built-in webgl which is odd because previously it was not using that because it thought it was deficient in required features.

@ Bill: ah, so, as of the current state of mozilla-central, there is no way to force it to use OSMesa, as the option webgl.software_render is basically ignored. If you are compiling from sources, you could apply the patch from bug 582053, which adds the config option webgl.force_osmesa, and set that to true. Another thing you could do, to force using OSMesa, is to disable GL hardware acceleration at the level of your X server configuration (don't know exactly how to do that).

(In reply to comment #10)
> @ Bill: ah, so, as of the current state of mozilla-central, there is no way to
> force it to use OSMesa, as the option webgl.software_render is basically
> ignored. If you are compiling from sources, you could apply the patch from bug
> 582053, which adds the config option webgl.force_osmesa, and set that to true.
> Another thing you could do, to force using OSMesa, is to disable GL hardware
> acceleration at the level of your X server configuration (don't know exactly
> how to do that).

OK. That allows me to once again run webgl demos (albeit slowly) using OSMesa.
So, it would seem that whatever testing we are doing now to figure out if the hardware support is sufficient for our needs might not be good enough? It previously automatically did the fallback to OSMesa for my driver. Of course, I understand that ATI had just released new open source drivers for my graphics adapter that probably resolve this issue, so this may all be moot.

It previously decided that my graphics driver did not support pbuffers and therefore fell back to software rendering. I have no idea what would have changed here. I am still running the same driver. Do we no longer require pbuffer support or do we just not test for it during initialization anymore?

(In reply to comment #5)
> Not e that in the APP notes, it says "X_CreateGC: BadDrawable (invalid Pixmap
> or Window parameter); 3 requests ago".

This is the fatal error. Running firefox with --sync would catch the bad caller.
But it looks like libc may not have frame pointers and so the stack is not so helpful.

If you have a debug Firefox build, X11Error would be the place to break.

Alternatively, with a mozilla.org build, if you can install libX11 symbols, then maybe you can try breaking in _XError, then signalling the process in gdb with "signal SIGABRT" to initiate the crash reporter.

(In reply to comment #12)
> It previously decided that my graphics driver did not support pbuffers and
> therefore fell back to software rendering. I have no idea what would have
> changed here. I am still running the same driver. Do we no longer require
> pbuffer support or do we just not test for it during initialization anymore?

We do no longer use PBuffers at all, at least on X11. Instead, we are now using framebuffer objects (FBOs).

So, the fact that you're getting this crash only when using your hardware-accelerated GL, not with OSMesa, is a hint that it might be a driver bug. Are you saying that you are using the ATI proprietary driver, aka "FGLRX" ?

Even if it turns out to be a driver bug that we can't do anything about, it's still interesting to know because we need to build a driver blacklist in order to feel good about enabling WebGL by default.

Looks like a similar report with better stack but on Arch Linux.
(Reporter is on FC12.)
bp-fe6605a3-7202-4ca9-9db0-472042100822

swrast_dri.so suggests Mesa.

Karl: what graphics setup do you have?

The backtrace says it crashed in a call to MakeCurrent during initialization of the GLX context. This is really strange. Here's the code of that function (in GLContextProviderGLX.cpp):

    PRBool MakeCurrent()
    {
        Bool succeeded = sGLXLibrary.xMakeCurrent(mDisplay, mDrawable, mContext);
        NS_ASSERTION(succeeded, "Failed to make GL context current!");
        return succeeded;
    }

The only thing that I can think of, making this crash, is if sGLXLibrary is bogus.

I don't like anyway that we're using a static object there (could slow down the startup) but perhaps it's worse than that, perhaps it's not properly initialized...

ah no, sorry! The error, "bad drawable", could also mean that there is something wrong with mDrawable.

So what happens is that WebGLContext.cpp calls CreateOffScreen to get its GL context. This calls CreateOffScreenPixmapContext (in GLContextProviderGLX.cpp). The "drawable" in question is the pixmap there. The code creating and checking it is (GLContextProviderGLX.cpp lines 590-606):

    nsRefPtr<gfxXlibSurface> xsurface = gfxXlibSurface::Create(DefaultScreenOfDisplay(display),
                                                               vinfo->visual,
                                                               gfxIntSize(16, 16));
    if (xsurface->CairoStatus() != 0) {
        return nsnull;
    }

    GLXPixmap glxpixmap = sGLXLibrary.xCreatePixmap(display,
                                                    cfgs[chosenIndex],
                                                    xsurface->XDrawable(),
                                                    NULL);
    if (glxpixmap == 0) {
        return nsnull;
    }

Do you see something wrong there?

The man page,

    http://www.opengl.org/sdk/docs/man/xhtml/glXCreatePixmap.xml

Doesn't seem to say that it returns 0 on error. On the other hand, it says that an error will be generated if the config "does not support rendering to windows (e.g., GLX_DRAWABLE_TYPE does not contain GLX_WINDOW_BIT)"

Our current config requirement doesn't have this bit:

    int attribs[] = {
        GLX_DOUBLEBUFFER, False,
        GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT,
        GLX_X_RENDERABLE, True,
        GLX_RED_SIZE, 1,
        GLX_GREEN_SIZE, 1,
        GLX_BLUE_SIZE, 1,
        GLX_ALPHA_SIZE, 0,
        GLX_DEPTH_SIZE, 0,
        0
    };

So maybe a patch would be to set this bit (patch coming).

Created attachment 468291
add GLX_WINDOW_BIT

This patch adds GLX_WINDOW_BIT, as the glXCreatePixmap suggests is needed...

This might only be an issue with osmesa, so I won't block on it for now. If it turns out to be a more general issue, please renom.

Joe: the original reporter thought he was running OSMesa, but realized in comment 12 that it was actually using his ATI driver.

(In reply to comment #22)
> Joe: the original reporter thought he was running OSMesa, but realized in
> comment 12 that it was actually using his ATI driver.

Yes I did not realize that the webgl.software_render preference was no longer honored, so this was using the XORG ATI drivers. When I switched to using OSMesa that actually avoided the issue.

I will try this patch tonight to see if it fixes my original issue.

(In reply to comment #19)
> The man page,
>
> http://www.opengl.org/sdk/docs/man/xhtml/glXCreatePixmap.xml
>
> ... says that
> an error will be generated if the config "does not support rendering to windows
> (e.g., GLX_DRAWABLE_TYPE does not contain GLX_WINDOW_BIT)"

I wonder whether that's an mixup with glXCreateWindow in the documentation.
I can't think why Windows would need to be supported for glxCreatePixmap.

It would be interesting to know whether the resourceid in the XErrorEvent passed to X11Error matches the mDrawable passed to MakeCurrent.

These errors are reported asynchronously, so we really need a stack from a run with --sync, to be certain that the problem is in MakeCurrent.

(In reply to comment #15)
> Even if it turns out to be a driver bug that we can't do anything about, it's
> still interesting to know because we need to build a driver blacklist in order
> to feel good about enabling WebGL by default.

I don't think a driver blacklist is the right approach here. This is the current Xorg driver for all ATI graphics adapters under fedora12. So, it would seem, either we don't do WebGL for ATI graphics or another solution is required.

Adding the GLX_WINDOW_BIT died not fix this.

I do have a 32-bit OS loaded on a USB drive. Perhaps I can get a better stack trace with proper debug info from that.

It might take a couple of days though.

(In reply to comment #26)
> (In reply to comment #15)
> > Even if it turns out to be a driver bug that we can't do anything about, it's
> > still interesting to know because we need to build a driver blacklist in order
> > to feel good about enabling WebGL by default.
>
> I don't think a driver blacklist is the right approach here. This is the
> current Xorg driver for all ATI graphics adapters under fedora12. So, it would
> seem, either we don't do WebGL for ATI graphics or another solution is
> required.

The adapter is identified as "ATI Radeon HD 3200 Graphics".

The driver is identified as:

(II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 1.7.4, module version = 6.12.99
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 6.0

(In reply to comment #21)
> If it turns out to be a more general issue, please renom.

I don't think we can consider crashing with this common driver acceptable.

(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #15)
> > > Even if it turns out to be a driver bug that we can't do anything about, it's
> > > still interesting to know because we need to build a driver blacklist in order
> > > to feel good about enabling WebGL by default.
> >
> > I don't think a driver blacklist is the right approach here. This is the
> > current Xorg driver for all ATI graphics adapters under fedora12. So, it would
> > seem, either we don't do WebGL for ATI graphics or another solution is
> > required.
>
> The adapter is identified as "ATI Radeon HD 3200 Graphics".
>
> The driver is identified as:
>
> (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
> (II) Module radeon: vendor="X.Org Foundation"
> compiled for 1.7.4, module version = 6.12.99
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 6.0

That all said it seems that installing the ATI proprietary driver fixes the issue.

It works fine with:

(II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
(II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
        compiled for 1.7.1, module version = 8.75.5
        Module class: X.Org Video Driver
(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
        compiled for 1.7.1, module version = 8.75.5
(II) ATI Proprietary Linux Driver Version Identifier:8.75.5
(II) ATI Proprietary Linux Driver Release Identifier: 8.753
(II) ATI Proprietary Linux Driver Build Date: Jun 29 2010 22:08:06

@ Bill :

What Karl says in comment 25, namely that we need a backtrace from a firefox run with the --sync command line option, is important. It's great that the ATI proprietary driver doesn't crash, but it would be great to know why it crashed with the other driver (if I understand well, it's with the open source radeon driver that it's crashing?). So if you find time to run with --sync, that would be very helpful.

Regarding comment 26: we'll do what we reasonably can to avoid crashing with a given driver, but if we can't make sure that we avoid crashing, it's better to blacklist the driver (blocking WebGL but not other web technologies) rather than allow a random web page to crash firefox.

What might actually be more useful and possibly easier to produce than a stack is a log from xtrace: http://xtrace.alioth.debian.org/.

If you can get an xtrace log, we probably only need the tail. If you can find the XID in the error event, then search back to the point where the XID was created, we probably don't need much before that. Or if it's easier to just post the whole log on a server somewhere, that's good too.

(In reply to comment #32)
> What might actually be more useful and possibly easier to produce than a stack
> is a log from xtrace: http://xtrace.alioth.debian.org/.
>
> If you can get an xtrace log, we probably only need the tail. If you can find
> the XID in the error event, then search back to the point where the XID was
> created, we probably don't need much before that. Or if it's easier to just
> post the whole log on a server somewhere, that's good too.

OK. I might have time to do this tonight. If not, definitely tomorrow.
I also had another couple of things to try as well, I need to uninstall the proprietary driver to get back tot eh failure, then was going to try a 64-bit firefox build to see if maybe it is some 32-bit library/64-bit driver interface issue. In any event I will get an xtrace log of the original issue 32-bit firefox 64-bit OS and 64-bit XORG ATI driver.

(In reply to comment #32)
> What might actually be more useful and possibly easier to produce than a stack
> is a log from xtrace: http://xtrace.alioth.debian.org/.
>
> If you can get an xtrace log, we probably only need the tail. If you can find
> the XID in the error event, then search back to the point where the XID was
> created, we probably don't need much before that. Or if it's easier to just
> post the whole log on a server somewhere, that's good too.

I might have more time to work on this tomorrow, but the current situation is that I can't get xtrace to work correctly on my system. I built the latest version I could find from xtrace_1.0.2.orig.tar.gz and it seemed to build and install correctly. I seem to be able to invoke it with no errors but I then seem to get "Unable to connect to display :9" on any attempt to use it.

However, I did make progress on other fronts. With exactly the same driver that crashes when I use it with a 32-bit build fo Firefox and hence the 32-bit X libraries it is crashing, bjut when I use the 64-bit version of Firefox and hence the 64-bit X libraries, it does not. It would seem perhaps that the issue here is not in Mozilla code but in that the XORG 32-bit libraries do not work correctly with the XORG 64-bit ATI driver.

I build Debian's 1.1.0 version from here:
http://packages.debian.org/sid/xtrace
http://ftp.de.debian.org/debian/pool/main/x/xtrace/xtrace_1.1.0.orig.tar.gz
(I don't recall much in the debian patch for that.)

and run with
 .../install/bin/xtrace -o output.xtrace minefield

Unfortunately I've hit the same issue, please see:
Bug 616416

http://www.html5test.com also crashes here.

This is probably the same bug as bug 613079 which is about to be marked resolved. Once this happens, can you please try the next nightly build.

I mean, just the X crash part of it. I'll notify this bug.

*** Bug 621699 has been marked as a duplicate of this bug. ***

OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 7.9.1
OpenGL shading language version string: 1.20

i.e. classic software renderer.

Breakpoint 1, _XError (dpy=0x7f1f3263c000, rep=0x7f1ee67fb2b0) at XlibInt.c:1554
1554 in XlibInt.c
(gdb) p *rep
$1 = {type = 0 '\000', errorCode = 9 '\t', sequenceNumber = 19214, resourceID = 27264635, minorCode = 0, majorCode = 55 '7', pad1 = 0 '\000', pad3 = 0, pad4 = 0, pad5 = 0, pad6 = 0, pad7 = 0}

i.e. BadDrawable, X_CreateGC

(gdb) bt
#0 _XError (dpy=0x7f1f3263c000, rep=0x7f1ee67fb2b0) at XlibInt.c:1554
#1 0x00007f1f38b6ecbf in handle_error (dpy=0x7f1f3263c000, err=0x7f1ee67fb2b0, in_XReply=1) at xcb_io.c:166
#2 0x00007f1f38b6ed06 in handle_response (dpy=0x7f1f3263c000, response=0x7f1ee67fb2b0, in_XReply=1) at xcb_io.c:266
#3 0x00007f1f38b6f2b0 in _XReply (dpy=0x7f1f3263c000, rep=<value optimized out>, extra=<value optimized out>, discard=<value optimized out>) at xcb_io.c:555
#4 0x00007f1f38b6a9b9 in XSync (dpy=0x7f1f3263c000, discard=0) at Sync.c:44
#5 0x00007f1f38b6ab7b in _XSyncFunction (dpy=0x7f1f3263c000) at Synchro.c:35
#6 0x00007f1f38b71847 in _XPrivSyncFunction (dpy=0x7f1f3263c000) at XlibInt.c:251
#7 0x00007f1f38b4a87a in XCreateGC (dpy=0x7f1f3263c000, d=0, valuemask=139771966222336, values=0x0) at CrGC.c:100
#8 0x00007f1f3438b742 in XCreateDrawable (base=0x7f1efbdefef0, xDrawable=27264635, drawable=<value optimized out>, modes=0x7f1ee689c800) at drisw_glx.c:78
#9 driCreateDrawable (base=0x7f1efbdefef0, xDrawable=27264635, drawable=<value optimized out>, modes=0x7f1ee689c800) at drisw_glx.c:377
#10 0x00007f1f3438baa7 in driFetchDrawable (gc=0x7f1f09e91300, glxDrawable=27264635) at dri_common.c:373
#11 0x00007f1f3438b26a in drisw_bind_context (context=0x7f1f3263c000, old=<value optimized out>, draw=1, read=19215) at drisw_glx.c:266
#12 0x00007f1f343694c1 in MakeContextCurrent (dpy=0x7f1f3263c000, draw=27264635, read=27264635, gc_user=<value optimized out>) at glxcurrent.c:263
#13 0x00007f1f3e9b197c in mozilla::gl::GLContextGLX::MakeCurrentImpl (this=0x7f1ee68df000, aForce=0) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:333
#14 0x00007f1f3d79b4f7 in mozilla::gl::GLContext::MakeCurrent (this=0x7f1ee68df000, aForce=0) at ../../../dist/include/GLContext.h:454
#15 0x00007f1f3e9b18b1 in mozilla::gl::GLContextGLX::Init (this=0x7f1ee68df000) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:313
#16 0x00007f1f3e9b15ff in mozilla::gl::GLContextGLX::CreateGLContext(const mozilla::gl::ContextFormat &, Display *, GLXDrawable, GLXFBConfig, struct {...} *, mozilla::gl::GLContextGLX *, PRBool, gfxXlibSurface *) (format=..., display=0x7f1f3263c000, drawable=27264635, cfg=0x7f1ee689c800, vinfo=0x7f1ee67ec800, shareContext=0x0, deleteDrawable=1, pixmap=0x7f1f18783ec0) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:268
#17 0x00007f1f3e9b0dd2 in mozilla::gl::CreateOffscreenPixmapContext (aSize=..., aFormat=..., aShare=0) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:650
#18 0x00007f1f3e9b133f in mozilla::gl::GLContextProviderGLX::GetGlobalContext () at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX...

This doesn't need to block stuff anymore since we have the blacklist in bug 624390. The present crash only happens anymore with a non-default switch on (MOZ_GLX_IGNORE_BLACKLIST).

As I said elsewhere, I can no longer reproduce this and I think the issue is that people wnho are still seeing this are running either out-of-date Linux Kernels or out-of-date graphics drivers. However depending on the Linux distro being used, they could be running the latest kernel and graphics driver available for that distro (albeit something that is really outdated). This is not really an easy issue.

7.9.1 is the latest stable mesa. This was with xorg-server 1.9.3.901, linux 2.6.36.3 and xf86-video-ati 6.13.2.

(In reply to comment #78)
> 7.9.1 is the latest stable mesa. This was with xorg-server 1.9.3.901, linux
> 2.6.36.3 and xf86-video-ati 6.13.2.

This all seems very disturbing. I was the original reporter of this issue. I could not get this to work at all using ATI graphics with the Xorg drivers under fedora 12. After updating to fedora 14, my issue completely disappeared.

I am running the following:

GLX version: 1.4
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20

It would seem that you are running something later than I am, yet you are seeing an issue left over form what I saw in a much older version. So, either this was fixed in the version I am running and subsequently broken again, or there is something more in play here than just driver version and blacklisting (or even white-listing) by driver version is not really going to do what is desired here.

It would be helpful if we could understand what is different here.
Bill, can you post the "OpenGL vendor string" and "OpenGL renderer string" from glxinfo on your Fedora 14 system, please?

(In reply to comment #80)
> It would be helpful if we could understand what is different here.
> Bill, can you post the "OpenGL vendor string" and "OpenGL renderer string" from
> glxinfo on your Fedora 14 system, please?

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101 TCL DRI2
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20

But same result on a different system where it is:

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium o.4 on RV410
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20

(In reply to comment #82)
> But same result on a different system where it is:
>
> OpenGL vendor string: X.Org R300 Project
> OpenGL renderer string: Gallium o.4 on RV410
                                  ^^^
                                  0.4
> OpenGL version string: 2.1 Mesa 7.9
> OpenGL shading language version string: 1.20

Thanks. It seem that this is WFM for Bill on Fedora 14 because that system has hardware GL support and so is no longer using Mesa's Software Rasterizer.

However, there will always be cards that don't have hardware support and so there will always be people on systems that have only software Mesa.

This bug is in the classic Software Rasterizer, though. I expect newer systems to move to Gallium on llvmpipe for software GL, which demonstrates bug 616416.

(In reply to comment #83)
> (In reply to comment #82)
> > But same result on a different system where it is:
> >
> > OpenGL vendor string: X.Org R300 Project
> > OpenGL renderer string: Gallium o.4 on RV410
> ^^^
> 0.4
> > OpenGL version string: 2.1 Mesa 7.9
> > OpenGL shading language version string: 1.20

The graphics adapter is an ATI Mobility Radeon X700

(In reply to comment #84)
> Thanks. It seem that this is WFM for Bill on Fedora 14 because that system has
> hardware GL support and so is no longer using Mesa's Software Rasterizer.
>
> However, there will always be cards that don't have hardware support and so
> there will always be people on systems that have only software Mesa.
>
> This bug is in the classic Software Rasterizer, though. I expect newer systems
> to move to Gallium on llvmpipe for software GL, which demonstrates bug 616416.

but then wh does the config form comment 81 work?

(In reply to comment #82)
> OpenGL vendor string: X.Org R300 Project
> OpenGL renderer string: Gallium 0.4 on RV410
> OpenGL version string: 2.1 Mesa 7.9
> OpenGL shading language version string: 1.20

Interestingly, that looks very similar to what I was using for bug 624935: same GL driver but slightly different hardware, and I gather you don't see that problem.

(In reply to comment #86)
"Mesa DRI R600 (RS780 9612) 20090101 TCL DRI2" uses hardware while "Software Rasterizer" is only software.

BTW, putting LIBGL_ALWAYS_SOFTWARE=1 in the environment will force use of a software rasterizer, which might be classic or Gallium.

(In reply to comment #88)
> (In reply to comment #86)
> "Mesa DRI R600 (RS780 9612) 20090101 TCL DRI2" uses hardware while "Software
> Rasterizer" is only software.
>
> BTW, putting LIBGL_ALWAYS_SOFTWARE=1 in the environment will force use of a
> software rasterizer, which might be classic or Gallium.

Sorry. didn't mean to jump all over you on you about this. Just I thought i could at least have a chance to post about what the 2 relevant hardware confugurations were.

(In reply to comment #81)
> (In reply to comment #80)
> > It would be helpful if we could understand what is different here.
> > Bill, can you post the "OpenGL vendor string" and "OpenGL renderer string" from
> > glxinfo on your Fedora 14 system, please?
>
> OpenGL vendor string: Advanced Micro Devices, Inc.
> OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101 TCL DRI2
> OpenGL version string: 2.1 Mesa 7.9
> OpenGL shading language version string: 1.20

This one is ATI Radeon HD 3200 Graphics.

Nay way both of those I reported seem to work just fine and run the entire flight of the navigator demo as well as all fo the webgl demos located here:

http://www.khronos.org/webgl/wiki/Demo_Repository

Bill, we're now in touch with xorg driver developers (#gfx on IRC, and taking this to the xorg-devel list asap) so good stuff may start happening :)

I should mention though that I do have an issue here where on flight of the navigator there seems to be 30% chance of an issue where it does crash at the transition point between the end of the video and the beginning of the credits with this showing up in /var/log/messages:

Jan 14 09:59:22 waglaptop kernel: [14228.737421] radeon 0000:01:05.0: r600_cs_track_check:362 mask 0x0000000F | 0x0000000F no cb for 0
Jan 14 09:59:22 waglaptop kernel: [14228.737427] radeon 0000:01:05.0: r600_packet3_check:1331 invalid cmd stream 471
Jan 14 09:59:22 waglaptop kernel: [14228.737430] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

(In reply to comment #87)
> (In reply to comment #82)
> > OpenGL vendor string: X.Org R300 Project
> > OpenGL renderer string: Gallium 0.4 on RV410
> > OpenGL version string: 2.1 Mesa 7.9
> > OpenGL shading language version string: 1.20
>
> Interestingly, that looks very similar to what I was using for bug 624935: same
> GL driver but slightly different hardware, and I gather you don't see that
> problem.

Actually with this card I do see the issue in that bug. I also see crashes on the economist.com site. However, the fact that this graphics card has long been unsupported by the manufacturer and worked so poorly under fedora 12 (issues having nothing to do with browsers) is the main reason I bought the new system with the more recent graphics card. I was actually pleasantly surprised that upgrading the system to fedora 14 actually resulted in Linux being usable with this card.

It is #3 top crasher on Linux in 4.0b9 for the last week.

I've made a tryserver build:

http://<email address hidden>/

To everybody who got crashes here, can you please run this, and in case of crashes, give me your whole terminal (standard error) output? You can log it into a file by doing e.g.

./firefox 2>&1 | tee logfile.txt

(In reply to comment #96)
> I've made a tryserver build:
>
> http://<email address hidden>/
>
> To everybody who got crashes here, can you please run this, and in case of
> crashes, give me your whole terminal (standard error) output? You can log it
> into a file by doing e.g.
>
> ./firefox 2>&1 | tee logfile.txt

Unfortunately, as I was the original reporter, I can no longer reproduce this with the non-proprietary ATI drivers, as I have subsequently updated all of my Linux systems to fedora 14 and the accompanying versions of Xorg and the associated graphics drivers.

I think this still might be reproducible under fedora14 using the Nouveau NVIDIA driver. If so I will attach that.

(In reply to comment #96)
> I've made a tryserver build:
> To everybody who got crashes here, can you please run this

I get a reproducable crash with Mesa Software GL and this Demo: http://www.chromeexperiments.com/detail/mandelbox/?f=webgl
bp-ee16aea2-5191-47aa-bd6e-5a38d2110205

Other WebGL Demos mostly work.
Are runs/crashes with tryserver-builds still wanted? (if yes, new url needed)

@ Stebs:

 please file new bugs with that; this bug report is getting too big. Please include the output of glxinfo | egrep -i vendor\|renderer\|version

It is #2 top crasher on Linux in 4.0b11.

Bug 632969 should fix this except for people who explicitly define MOZ_GLX_IGNORE_BLACKLIST.

(In reply to comment #101)
> Bug 632969 should fix this except for people who explicitly define
> MOZ_GLX_IGNORE_BLACKLIST.

I would expect this is people who explicitly define the environment variable in order to test and comment in bug 624593.

I looked through a selection of the #2 Linux 4.0b11 crasher reports and didn't see any with X_CreateGC: BadDrawable in the AppNotes, so either I got very unlucky or the number of reports that are this bug is small.

Removing [@ linux-gate.so@0xXXX ] as all that means is that the program was signalled in a system call. Associating all such crashes with this bug is misleading.

Now that bug 616416 is fixed, Gallium on llvmpipe also runs into this.

This is now caught by the simple glxtest:

(gdb) p /x *(xCreateGCReq*)0x7ffff6d7f044
$17 = {reqType = 0x37, pad = 0x0, length = 0x4, gc = 0x3200004, drawable = 0x3200002, mask = 0x0}

(gdb) bt
#0 _XError (dpy=0x7ffff6d76000, rep=0x7ffff6da3dc0)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/XlibInt.c:1558
#1 0x00007ffff0463eff in handle_error (dpy=0x7ffff6d76000, err=0x7ffff6da3dc0, in_XReply=1)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/xcb_io.c:166
#2 0x00007ffff0463f46 in handle_response (dpy=0x7ffff6d76000, response=0x7ffff6da3dc0,
    in_XReply=1) at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/xcb_io.c:266
#3 0x00007ffff04644f0 in _XReply (dpy=0x7ffff6d76000, rep=<value optimized out>,
    extra=<value optimized out>, discard=<value optimized out>)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/xcb_io.c:566
#4 0x00007ffff045fbf9 in XSync (dpy=0x7ffff6d76000, discard=0)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/Sync.c:44
#5 0x00007ffff045fdbb in _XSyncFunction (dpy=0x7ffff6d76000)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/Synchro.c:35
#6 0x00007ffff0466a87 in _XPrivSyncFunction (dpy=0x7ffff6d76000)
    at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/XlibInt.c:251
#7 0x00007ffff043fa7a in XCreateGC (dpy=0x7ffff6d76000, d=0, valuemask=140737334734916,
    values=0x0) at /var/tmp/portage/x11-libs/libX11-1.4.3/work/libX11-1.4.3/src/CrGC.c:100
#8 0x00007fffec51b1a2 in XCreateDrawable (base=0x7ffff6d72900, xDrawable=52428802,
    drawable=<value optimized out>, modes=0x7ffff6d51f00) at drisw_glx.c:78
#9 driCreateDrawable (base=0x7ffff6d72900, xDrawable=52428802, drawable=<value optimized out>,
    modes=0x7ffff6d51f00) at drisw_glx.c:377
#10 0x00007fffec51b507 in driFetchDrawable (gc=0x7ffff6d4b360, glxDrawable=52428802)
    at dri_common.c:373
#11 0x00007fffec51acca in drisw_bind_context (context=0x7ffff6d76000, old=<value optimized out>,
    draw=1, read=20) at drisw_glx.c:266
#12 0x00007fffec4f8f01 in MakeContextCurrent (dpy=0x7ffff6d76000, draw=52428802, read=52428802,
    gc_user=<value optimized out>) at glxcurrent.c:265
#13 0x00007ffff236cae9 in glxtest () at /home/karl/moz/dev/toolkit/xre/glxtest.cpp:184
#14 0x00007ffff236ccb0 in fire_glxtest_process () at /home/karl/moz/dev/toolkit/xre/glxtest.cpp:242
#15 0x00007ffff23569c2 in XRE_main (argc=1, argv=0x7fffffffdfd8, aAppData=0x7ffff6d1b240)
    at /home/karl/moz/dev/toolkit/xre/nsAppRunner.cpp:2627
#16 0x0000000000401ec7 in do_main (
    exePath=0x7fffffffcec0 "/home/karl/moz/dev/obj/dist/bin/libxpcom.so", argc=1,
    argv=0x7fffffffdfd8) at /home/karl/moz/dev/browser/app/nsBrowserApp.cpp:191
#17 0x000000000040205d in main (argc=1, argv=0x7fffffffdfd8)
    at /home/karl/moz/dev/browser/app/nsBrowserApp.cpp:246
(gdb) p *rep
$19 = {type = 0 '\000', errorCode = 9 '\t', sequenceNumber = 19, resourceID = 52428802,
  minorCode = 0, majorCode = 55 '7', pad1 = 0 '\000', pad3 = 0, pad4 = 0, pad5 = 0, pad6 = 0,
  pad7 = 0}
(gdb) p /x *rep
$20 = {type = 0x0, errorCode = 0x9, sequenceNumber = 0x13, resourceID = 0x3200002,
  mino...

The "failed to create drawable" bug is
https://bugs.freedesktop.org/show_bug.cgi?id=27682
also reported at
https://bugs.freedesktop.org/show_bug.cgi?id=33758#c1
and looks quite likely to be the cause of the failure in MakeCurrent.

*** Bug 667439 has been marked as a duplicate of this bug. ***

*** Bug 717663 has been marked as a duplicate of this bug. ***