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).

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

(In reply to comment #35) > 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 OK that worked better. The complete bzipped trace is at http://www.wg9s.com/589546.xtrace.bz2

(In reply to comment #34) > 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. It turns out that this is really NOT the issue. Under a 32-bit OS with the 32-bit XORG driver and 32-bit libraries with 32-bit Firefox it still crashes.

Thanks for your help, Bill. Would you be able to attach the output from glxinfo for the server from which the xtrace was generated, please? > 001:<:28df: 12: GLX-Request(152,19): glXQueryServerString context_tag=0x00000000 name=LINES(0x00000001) > 001:>:28df:36: Reply to glXQueryServerString: n=0 num_properties=4 string=0x53,0x47,0x49,0x00; > 001:<:28e0: 4: Request(43): GetInputFocus > 001:>:28e0:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x0440008c > 001:<:28e1: 16: Request(53): CreatePixmap depth=0x18 pid=0x04400485 drawable=0x00000124 width=16 height=16 > 001:<:28e2: 24: GLX-Request(152,22): glXCreatePixmap opcode=0x98 opcode2=0x16 unparsed-data=0x00,0x00,0x00,0x00,0x86,0x00,0x00,0x00,0x85,0x04,0x40,0x04,0x86,0x04,0x40,0x04,0x00,0x00,0x00,0x00; > 001:<:28e3: 16: Request(53): CreatePixmap depth=0x18 pid=0x04400487 drawable=0x00000124 width=16 height=16 > 001:<:28e4: 24: GLX-Request(152,22): glXCreatePixmap opcode=0x98 opcode2=0x16 unparsed-data=0x00,0x00,0x00,0x00,0x86,0x00,0x00,0x00,0x87,0x04,0x40,0x04,0x88,0x04,0x40,0x04,0x00,0x00,0x00,0x00; screen = 0 fbconfig = 0x86 pixmap = 0x04400487 glxpixmap = 0x04400488 numAttribs = 0 > 001:<:28e5: 28: GLX-Request(152,24): glXCreateNewContext opcode=0x98 opcode2=0x18 unparsed-data=0x89,0x04,0x40,0x04,0x86,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x14,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x73,0x68,0x61; context = 0x04400489 fbconfig = 0x86 screen = 0 renderType = 0x8014 shareList = 0 isDirect = TRUE reserved1 = 0x73 reserved2 = 0x6168 > 001:<:28e6: 4: Request(43): GetInputFocus > 001:>:28e6:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x0440008c The GetInputFocus gets a reply, so no X11 errors generated so far. (I don't know whether there might be GL error at this point, though.) > 001:<:28e7: 16: Request(55): CreateGC cid=0x0440048a drawable=0x04400488 values={} > 001:<:28e8: 16: Request(55): CreateGC cid=0x0440048b drawable=0x04400488 values={} > 001:<:28e9: 4: Request(43): GetInputFocus > 001:>:28e7:Error 9=Drawable: major=55, minor=0, bad=71304328 > 001:>:28e8:Error 9=Drawable: major=55, minor=0, bad=71304328 The error involved XID 71304328 == 0x4400488, which is the XID for the glxpixmap that the second glXCreatePixmap was meant to create.

If we are not going to turn on webgl.enabled_for_all_sites for Firefox 4, then I guess this doesn't need to block.

I don't know whether or not it is reasonable to pass a glxpixmap id as the drawable for CreateGC. I don't have a sufficient GLX locally to see what happens when this works. Found extension GL_EXT_framebuffer_object WARNING: Error resizing offscreen framebuffer -- framebuffer not complete: file /home/karl/moz/dev/gfx/thebes/GLContext.cpp, line 672 GL Context 0x7f83edd2d800 deleting resource 0, which doesn't exist!== GLContext 0x7f83edd08000 == Outstanding Textures: Outstanding Buffers: Outstanding Programs: Outstanding Shaders: Outstanding Framebuffers: Outstanding Renderbuffers: WebGL: Can't get a usable OpenGL context.

Bill, do you get a similar crash with fullscreen video? e.g. http://audio-video.gnu.org/video/.original_files/rms-speech-patents-calgary-20050518-720x480.ogg (context menu -> full screen)

Before I get the errors on my system (with radeon from xf86-video-ati-6.13.1), glXCreateNewContext actually succeeds, but doesn't use CreateGC. It issues some DRI2-Requests in addition to the GLX-Request.

Renoming, based on bug 575738, so it probably doesn't matter whether or not this also affects video.

(In reply to comment #38) > Thanks for your help, Bill. Would you be able to attach the output from > glxinfo for the server from which the xtrace was generated, please? Ideally, that would be from a 32-bit glxinfo, if possible. If not practical, can we get glxinfo from the 32-bit system too, please?

(In reply to comment #41) > Bill, do you get a similar crash with fullscreen video? > > e.g. > http://audio-video.gnu.org/video/.original_files/rms-speech-patents-calgary-20050518-720x480.ogg > (context menu -> full screen) Yes. That crashes also. bp-41b68a39-2314-4344-9138-210722100823

This is the requested glxinfo output from 32-bit glxinfo on my 64-bit system.

(In reply to comment #45) > (In reply to comment #41) > > Bill, do you get a similar crash with fullscreen video? > > > > e.g. > > http://audio-video.gnu.org/video/.original_files/rms-speech-patents-calgary-20050518-720x480.ogg > > (context menu -> full screen) > > Yes. That crashes also. > > bp-41b68a39-2314-4344-9138-210722100823 So should we reassign to Core:Graphics? Have you tried running with OpenGL-accelerated layers turned on? Just set the environment variable, MOZ_ACCELERATED=1 People are looking for more testing of this feature before turning it on and since full-screen video crashes for you, it seems likely that this will crash too...

(In reply to comment #47) > Have you tried running with OpenGL-accelerated layers turned on? Just set the > environment variable, > > MOZ_ACCELERATED=1 This crashes for me as well. bp-25f4327d-7e2c-4329-a8d9-d51eb2100825

(In reply to comment #48) > (In reply to comment #47) > > Have you tried running with OpenGL-accelerated layers turned on? Just set the > > environment variable, > > > > MOZ_ACCELERATED=1 > > This crashes for me as well. > > bp-25f4327d-7e2c-4329-a8d9-d51eb2100825 Is it crashing for you in pages that don't have any WebGL or video?

Yes. It never got as far as displaying any browser chrome before it crashed.

Thanks, so I have renamed and re-categorized your bug.

Looks like https://bugzilla.redhat.com/show_bug.cgi?id=578782 I get the same error here with LIBGL_ALWAYS_SOFTWARE=1, though something is suppressing the original BadDrawable, so instead I see jemalloc errors or X_FreeGC: BadGC. > OpenGL renderer string: Software Rasterizer For fullscreen video, I expect we should prefer Render over software GL. I don't know what the WebGL plan is.

XRender is not useful for WebGL, we really need a GL there.

May bug 589671 be related or even be the same issue as this one?

(In reply to comment #54) I don't think they are related. This sounds like a bug in Meas, but bug 589671 happens with NVIDIA drivers.

Well try running the command: glxinfo | grep OpenGL and make sure it does not say it is using Mesa Software Rendering. If it does then it is this bug, if it does not it is a different bug.

It must be a different bug: $ glxinfo | grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8600 GT/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 256.44 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler OpenGL extensions:

OK. the reason I said to check is that while I was googling for possible ways to fix my issue, I found some Linux posts about people having problems getting it to switch to using NVIDIA drivers after they installed them.

(In reply to comment #55) > (In reply to comment #54) > I don't think they are related. This sounds like a bug in Meas, but bug 589671 > happens with NVIDIA drivers. I'm not entirely sure that our bug here is Mesa related, e.g. this guy on a french forum is having the crash with the ATI proprietary driver: http://linuxfr.org/comments/1155681.html#1155681 which makes me afraid that it's really a bug on our side (if his report is accurate and if it's actually the same bug).

X_GLXMakeCurrent: BadMatch sounds like a different bug, possibly more likely to be on our side. Could the drawable and context have different visuals? Given that I can only reproduce this bug with LIBGL_ALWAYS_SOFTWARE=1, this bug sounds software Mesa related.

Mostly for interest's sake, but maybe it could provide a solution on systems with software Mesa: Putting LIBGL_ALWAYS_INDIRECT=1 in the environment on the 64-bit system should make the 32-bit firefox use the server's GL and so behave similarly to (but not quite the same as) a 64-bit firefox. On the 32-bit system, that might make use of in-server software GL rather than client-side GL. Indirect GLX may have been more widely tested (as it is used by compositing window managers), so just maybe software Mesa works better in-server than client-side. (It might also crash the X server - I don't know.) glxinfo can also be run with LIBGL_ALWAYS_INDIRECT=1 to find out what the server uses for indirect GLX.

(In reply to comment #61) > Mostly for interest's sake, but maybe it could provide a solution on systems > with software Mesa: > > Putting LIBGL_ALWAYS_INDIRECT=1 in the environment on the 64-bit system should > make the 32-bit firefox use the server's GL and so behave similarly to (but not > quite the same as) a 64-bit firefox. > > On the 32-bit system, that might make use of in-server software GL rather than > client-side GL. Indirect GLX may have been more widely tested (as it is used > by compositing window managers), so just maybe software Mesa works better > in-server than client-side. (It might also crash the X server - I don't know.) > > glxinfo can also be run with LIBGL_ALWAYS_INDIRECT=1 to find out what the > server uses for indirect GLX. You seem to be making the assumption that this all works if I run a 64-bit version of Firefox. It does not. Setting LIBGL_ALWAYS_INDIRECT=1 just makes it decide to bypass trying to use the hardware acceleration. Basically is the same as setting the preference webgl.force_osmesa to true. glxinfo does not really show anything different as far as I can tell.

(In reply to comment #62) > You seem to be making the assumption that this all works if I run a 64-bit > version of Firefox. It does not. Yes, I was making that mis-assumption. Thank you for correcting it. > Setting LIBGL_ALWAYS_INDIRECT=1 just makes it decide to bypass trying to use > the hardware acceleration. Basically is the same as setting the preference > webgl.force_osmesa to true. Maybe it is similar on some systems, but I wouldn't expect that on systems that support accelerated indirect GLX (AIGLX). > glxinfo does not really show anything different as far as I can tell. Thanks for having a look.

Benoit tells me that you're the best person to look at this, Karl. If this is strictly a mesa bug, we should probably unblock on it, though.

Ok, until we're shown concrete proof that this is a problem on non-software OpenGL, this doesn't block.

(In reply to comment #65) > Ok, until we're shown concrete proof that this is a problem on non-software > OpenGL, this doesn't block. Well that still means that for some set of graphics adapters, using the XORG drivers for the graphics adapter, because it uses software xrendering, things are going to crash.

(In reply to comment #65) > Ok, until we're shown concrete proof that this is a problem on non-software > OpenGL, this doesn't block. I don't understand why a crash bug's blocking flag depends on whether or not the driver is using software for GL. The software GL is a very common GL implementation. IMO we should at least not be using software GL for video, and, now that WebGL is enabled by default, if we can't determine the cause of the crash, we should black-list this driver for WebGL.

I have this crash sometimes with minefield by setting layer acceleration on, without Mesa on Linux x86. OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 6150SE nForce 430/PCI/SSE2/3DNOW! OpenGL version string: 2.1.2 NVIDIA 260.19.12 OpenGL shading language version string: 1.20 NVIDIA via Cg compiler OpenGL extensions: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101030 Firefox/4.0b8pre

Oh sorry, wrong bug. Console output is X_GetGeometry: BadDrawable...

This seems to no longer be an issue with newer fedora releases. Since fedora 12 will be end of life in less than 3 weeks, this would seem to no longer be an issue.

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.

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.cpp:750 #19 0x00007f1f3e9b0163 in mozilla::gl::GetGlobalContextGLX () at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:405 #20 0x00007f1f3e9b0d6e in mozilla::gl::CreateOffscreenPixmapContext (aSize=..., aFormat=..., aShare=1) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:650 #21 0x00007f1f3e9b0e83 in mozilla::gl::GLContextProviderGLX::CreateOffscreen (aSize=..., aFormat=...) at /home/karl/moz/dev/gfx/thebes/GLContextProviderGLX.cpp:662 #22 0x00007f1f3d7975a2 in mozilla::WebGLContext::SetDimensions (this=0x7f1ee67eac00, width=425, height=330) at /home/karl/moz/dev/content/canvas/src/WebGLContext.cpp:480 #23 0x00007f1f3d848506 in nsHTMLCanvasElement::UpdateContext (this=0x7f1f08bae600, aNewContextOptions=0x0) at /home/karl/moz/dev/content/html/content/src/nsHTMLCanvasElement.cpp:611 #24 0x00007f1f3d8480ae in nsHTMLCanvasElement::GetContext (this=0x7f1f08bae600, aContextId=..., aContextOptions=..., aContext=0x7fff8f967840) at /home/karl/moz/dev/content/html/content/src/nsHTMLCanvasElement.cpp:534

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://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bjacob@mozilla.com-55faeffbd9db/ 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://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bjacob@mozilla.com-55faeffbd9db/ > > 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, minorCode = 0x0, majorCode = 0x37, pad1 = 0x0, pad3 = 0x0, pad4 = 0x0, pad5 = 0x0, pad6 = 0x0, pad7 = 0x0} (gdb) f 13 #13 0x00007ffff236cae9 in glxtest () at /home/karl/moz/dev/toolkit/xre/glxtest.cpp:184 184 glXMakeCurrent(dpy, glxpixmap, context); (gdb) p /x glxpixmap $22 = 0x3200002 (gdb) p /x pixmap $23 = 0x3200001 Passing the GLXPixmap id as a drawable to XCreateGC is consistent with comment 38. There is a "failed to create drawable" message printed during glXCreatePixmap. glGetError() returns 0 after glXCreatePixmap. LIBGL_DEBUG=verbose doesn't provide useful info. OpenGL renderer string: Gallium 0.4 on llvmpipe OpenGL version string: 2.1 Mesa 7.10.3

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.

This WFM now with Mesa 7.11.2 swrast, gallium or classic.

Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20121110034503 CSet: b53dbef72a55 bp-b101b6b9-1610-4e3f-a0f5-8fe172121115 bp-17359f52-e435-46bd-9a73-c73aa2121115 I got this twice in succession when trying to browse about:support, after I had tried Help → Troubleshooting Information which hadn't given me anything (no reaction on the mouse click, instead of opening the about:support page).

P.S. "App Notes" from the crash report: OpenGL: Mesa Project -- Software Rasterizer -- 2.1 Mesa 7.11 -- texture_from_pixmap X_FreeGC: BadGC (invalid GC parameter); 10 requests agoxpcom_runtime_abort(###!!! ABORT: X_FreeGC: BadGC (invalid GC parameter); 10 requests ago: file /builds/slave/m-esr17-lnx64-ntly/build/toolkit/xre/nsX11ErrorHandler.cpp, line 157)

Tony, you hit bug 799544.

(In reply to Scoobidiver from comment #112) > Tony, you hit bug 799544. Ah, sorry, Socorro proposed so many bugs I wasn't sure which one to choose, and bug 717663 (duped to here) seemed similar to what I had.