Everytime I try to load about:support in Firefox 16.0b6 with my profile I get a crash with the signature [@ mozalloc_abort | NS_DebugBreak_P | X11Error ]. The crash does not reproduce on a new profile, nor does it reproduce if I use the "crash" profile on Firefox 10.0.8esr. My profile is pretty new (only created a few days ago). I'm not sure what is happening or if this is a real issue. Please advise what information I can provide. Here are some crash reports: http://crash-stats.mozilla.com/report/index/bp-ccf2ff57-cdcb-44e0-8a5b-79db62121009 http://crash-stats.mozilla.com/report/index/bp-b73cc01c-24ab-4ea3-a7b3-af1b62121009 http://crash-stats.mozilla.com/report/index/bp-2246095d-ca3c-4b0b-ad33-7c9e22121009

Did some more testing across versions. The following builds do NOT crash: * Firefox 19.0a1 Nightly 2012-10-09 * Firefox 18.0a2 Aurora 2012-10-09 The following builds DO crash: * Firefox 16.0b6 * Firefox 16.0 release * Firefox 17.0 beta-debug 2012-10-09

It's bug 717663 which has been duped to bug 589546, closed as WFM!

According to bug 589546 comment 109, this was WFM with Mesa 7.11.2. Checking glxinfo it looks like I am running Mesa 7.10.3 (latest version provided by my distro). Does that make this WONTFIX/INVALID?

Here is the about of the Firefox 17 Beta debug build, in case it helps: JavaScript warning: chrome://global/content/aboutSupport.js, line 285: WebGL: Can't get a usable WebGL context WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../widget/xpwidgets/GfxInfoWebGL.cpp, line 42 ###!!! ABORT: X_FreeGC: BadGC (invalid GC parameter); 6 requests ago; id=0x2800ad7 Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.: file ../../../toolkit/xre/nsX11ErrorHandler.cpp, line 157 _XError+0x000000CC [/usr/lib/libX11.so.6 +0x00047B6C] UNKNOWN [/usr/lib/libX11.so.6 +0x0004EF8C] _XReply+0x00000140 [/usr/lib/libX11.so.6 +0x0004F630] XGetWindowProperty+0x000000C7 [/usr/lib/libX11.so.6 +0x0002C6E7] gdk_property_get+0x000001B3 [/usr/lib/libgdk-x11-2.0.so.0 +0x000659F3] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x0143D88C] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x0143CF73] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00D9C7BF] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00D9FB26] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00D9FB3E] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00D9FDBF] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00978335] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x016BCA4A] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x016BCBCA] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x016B8A63] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x01677ABF] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x01549AF0] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x016E472C] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x016E4754] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x014618A1] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x012B4E7B] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x00742123] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x0074245A] XRE_main+0x0000003B [/home/ashughes/downloads/firefox-debug/firefox/libxul.so +0x007425E5] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/firefox +0x000022A6] __libc_start_main+0x000000FD [/lib/libc.so.6 +0x0001EC8D] UNKNOWN [/home/ashughes/downloads/firefox-debug/firefox/firefox +0x00001B79] ###!!! ABORT: X_FreeGC: BadGC (invalid GC parameter); 6 requests ago; id=0x2800ad7 Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.: file ../../../toolkit/xre/nsX11ErrorHandler.cpp, line 157

Running with MOZ_X_SYNC=1 as the output suggests actually makes this crash unreproducible. Here's the output from my about:support graphics section... Graphics Adapter Description: Mesa Project -- Software Rasterizer Vendor ID: Mesa Project Device ID: Software Rasterizer Driver Version: 2.1 Mesa 7.10.3 WebGL Renderer: false GPU Accelerated Windows: 0 AzureCanvasBackend: none AzureFallbackCanvasBackend: none AzureContentBackend: none

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #3) > According to bug 589546 comment 109, this was WFM with Mesa 7.11.2. Checking > glxinfo it looks like I am running Mesa 7.10.3 (latest version provided by > my distro). I think a downloaded gfx blocklist should be set if it works for Linux (driver version is alphanumeric).

I wonder whether this might be a regression from bug 680644. What used to save us from bug 717663 was that glxtest crashed and we detected that. (I can't recall whether it was a 100% reliable crash, or whether sometimes it got through and we failed to catch.) Perhaps changes in bug 680644 mean that glxtest no longer crashes. When running "strace -e ipc /path/to/firefox" the SIGCHLD line will indicate whether the child process exits successfully. MOZ_AVOID_OPENGL_ALTOGETHER=1 in the environment should workaround the problem in Firefox 18.

Has anybody else been able to reproduce Anthony's crash or seen reports of this on SUMO?

Note that I am using a distro which is a bit behind the curve for stability (based on Debian Squeeze). Ubuntu and Fedora (two of the most popular distros) are a bit ahead of the curve. If this is truly "fixed" in a newer version of the kernel or Mesa drivers, it might not be worth tracking since the lion's share of Linux users might be on "fixed" software.

I've not seen a single report of this on input or SUMO. That doesn't mean much though as it's a pretty small user group and a bit of narrow use case.

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

P.S. …and I am on openSUSE Linux 12.1 because although 12.2 has been released on September 5, it refuses to install here.

We haven't had enough external reports to warrant tracking for a release.

(In reply to Alex Keybl [:akeybl] from comment #13) > We haven't had enough external reports to warrant tracking for a release. Well, OK. I think all hell is gonna break loose if an Extended Support Release gets released with a known crashing bug in it, but I might be wrong.

(In reply to Tony Mechelynck [:tonymec] from comment #11) > OpenGL: Mesa Project -- Software Rasterizer -- 2.1 Mesa 7.11 -- > texture_from_pixmap Update to Mesa 7.11.2 as stated in comment 3.

(In reply to Scoobidiver from comment #15) > (In reply to Tony Mechelynck [:tonymec] from comment #11) > > OpenGL: Mesa Project -- Software Rasterizer -- 2.1 Mesa 7.11 -- > > texture_from_pixmap > Update to Mesa 7.11.2 as stated in comment 3. I can't: the version I have is the highest one available on the software repositories for openSUSE 12.1, and I can't update to 12.2 because if I disable floppies in the BIOS, it won't load my GRUB bootloader, and if I enable them, the update hangs while scanning for Linux partitions. (There are no floppy drives on this machine.) This said, don't higher Gecko versions (19.0a1 for instance) recognise that my OpenGL version is buggy and disable it? In SeaMonkey 2.16a1, about:support (which doesn't crash) tells me: Graphics Adapter Description: Mesa Project -- Software Rasterizer Device ID: Software Rasterizer Driver Version: 2.1 Mesa 7.11 GPU Accelerated Windows: 0/4 Basic Vendor ID: Mesa Project AzureCanvasBackend: cairo AzureContentBackend: none AzureFallbackCanvasBackend: none

It's indeed fixed in 18.0 by an unknown patch (see comment 1) that we should find and uplift to ESR17.

(In reply to Scoobidiver from comment #17) > It's indeed fixed in 18.0 by an unknown patch (see comment 1) that we should > find and uplift to ESR17. OK, so first thing is finding it. It was either fixed on 18.0a1 and not ported to aurora, or fixed on 19.0a1 and ported to aurora but not to beta. IIUC this means it was fixed no earlier than 2012-08-27. How do I further narrow the search? Bugs for Core::Canvas:WebGL maybe… That gives me 28 bugs including 2 crashes, https://bugzilla.mozilla.org/buglist.cgi?order=Last%20Changed;list_id=4978156;resolution=FIXED;classification=Components;chfieldto=Now;query_format=advanced;chfield=resolution;chfieldfrom=2012-08-27;chfieldvalue=FIXED;component=Canvas%3A%20WebGL;product=Core What do you think?

(In reply to Tony Mechelynck [:tonymec] from comment #18) > What do you think? You should use https://github.com/mozilla/mozregression to find the working range.

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b038e9e2023f&tochange=895f66c4eada

(In reply to Tony Mechelynck [:tonymec] from comment #14) > Well, OK. I think all hell is gonna break loose if an Extended Support > Release gets released with a known crashing bug in it, but I might be wrong. We ship all releases with known bugs, including crashers, the question is just a risk analysis (risk of increased badness for users vs. risk to code and shipment dates). When you find what fixed it, the chance to get the fix into at least an update on ESR increases, depending on how intrusive the patch is.

(In reply to Tony Mechelynck [:tonymec] from comment #20) > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=b038e9e2023f&tochange=895f66c4eada I see two changesets with "WebGL" in the commit message (bug 791905 and bug 791521, both among the "83 hidden changesets" of merge changeset 2d96ee8d9dd4) but neither seems to fit the bill.

(In reply to Tony Mechelynck [:tonymec] from comment #16) > This said, don't higher Gecko versions (19.0a1 for instance) recognise that > my OpenGL version is buggy and disable it? In SeaMonkey 2.16a1, > about:support (which doesn't crash) tells me: > > Graphics > > Adapter Description: Mesa Project -- Software Rasterizer > Device ID: Software Rasterizer > Driver Version: 2.1 Mesa 7.11 > GPU Accelerated Windows: 0/4 Basic > Vendor ID: Mesa Project > AzureCanvasBackend: cairo > AzureContentBackend: none > AzureFallbackCanvasBackend: none 'Software rasterizer' means the very old software mesa driver, 'swrast'. It's known to be bad indeed. We should blacklist it.

(In reply to Benoit Jacob [:bjacob] from comment #23) > 'Software rasterizer' means the very old software mesa driver, 'swrast'. > It's known to be bad indeed. We should blacklist it. It seems that the patches of bug 791905 or bug 791521 have the same effect. One of them should be uplifted to ESR17.

(In reply to Scoobidiver from comment #24) > (In reply to Benoit Jacob [:bjacob] from comment #23) > > 'Software rasterizer' means the very old software mesa driver, 'swrast'. > > It's known to be bad indeed. We should blacklist it. > It seems that the patches of bug 791905 or bug 791521 have the same effect. > One of them should be uplifted to ESR17. Hm, they may have the same effect on this particular page, but we still need to blacklist that driver. I think it's too late to uplift anything to ESR17 at this point since it's going to be released in a few days, but what we can do is use a downloaded blacklist rule if this is deemed important enough.

(In reply to Benoit Jacob [:bjacob] from comment #26) > I think it's too late to uplift anything to ESR17 at this point since it's > going to be released in a few days, but what we can do is use a downloaded > blacklist rule if this is deemed important enough. ESR 17 means any minor versions between 17.0 and 24.0.

Oh OK. So the other problem with backporting bug 791521 to ESR17 is that this will break about:support WebGL Renderer, and fixing it will require backporting large patches (bug 742781, bug 795701). So it's far more practical to just blacklist this in ESR17. The present patch can be backported for the next minor version, or we can do a downloaded blacklist rule at any time.

This also affected Gallium on llvmpipe with Mesa 7.10.3 (bug 589546 comment 104 and 105). 8.0.4 Software Rasterizer seems to work without crashing on http://people.mozilla.com/~sicking/webgl/ray.html but is much much slower than llvmpipe.

OK, I requested ESR approval for 791521. To put things in perspective we are not very far away from blacklisting Mesa altogether due to security issues, so we're past the point where we would go out of our way to support the _old_ mesa software rasterizer.

(In reply to Benoit Jacob [:bjacob] from comment #30) > OK, I requested ESR approval for 791521. > > To put things in perspective we are not very far away from blacklisting Mesa > altogether due to security issues, so we're past the point where we would go > out of our way to support the _old_ mesa software rasterizer. If the crash can be avoided, it would IMHO be a serious thorn out of our heel. Slow performance isn't fun but it's better than crashing, and having a "Graphics" section in about:support which says nothing else than "GPU Accelerated Windows: 0/4" might even, as you said in bug 791521 comment #8, be overlooked by most enterprise users. What is llvmpipe? I don't see it on my distro's software repositories, and "llvm" seems to be a compiler enhancement AFAICT. If the answer would take too much space on the bug, feel free to email me privately, or to ping me on moznet.

llvmpipe and softpipe are alternative software GL implementations within Mesa using the newer Gallium3D architecture. http://www.mesa3d.org/llvmpipe.html Switching from the classic software implementation within Mesa to either of the gallium implementations will not avoid this bug. A different version of Mesa, with this bug fixed, is required. If Mesa is going to be blacklisted altogether, then we should give up on WebGL and GL layers on desktop linux. Blacklisting older Mesa software implementations would work around this bug enough to avoid this crash.

Could this be uplifted to firefox19 ? Since the beta upgraded to 19, I've had several crashes, including a reproducible one on http://moztrap.mozilla.org/ . Crash example: https://crash-stats.mozilla.com/report/index/bp-85b565ac-b158-47a8-9840-3c6032130131 And I'm not alone: https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A19.0b3&version=Firefox%3A19.0b4&version=Firefox%3A19.0b2&version=Firefox%3A19.0b1&platform=linux&range_value=3&range_unit=weeks&date=01%2F31%2F2013+16%3A45%3A51&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1 Configuring webgl.disabled = true fixes it though, but it requires user intervention.

(In reply to Aissen from comment #35) > And I'm not alone: > https://crash-stats.mozilla.com/query/ > query?product=Firefox&version=Firefox%3A19.0b3&version=Firefox%3A19. > 0b4&version=Firefox%3A19.0b2&version=Firefox%3A19. > 0b1&platform=linux&range_value=3&range_unit=weeks&date=01%2F31%2F2013+16%3A45 > %3A51&query_search=signature&query_type=contains&query=&reason=&build_id=&pro > cess_type=any&hang_type=any&do_query=1 This crash signature is for five kinds of crashes. Checking manually crash reports without duplicates in 19.0b3, I see only four crashes in 19.0b3 which is very low. We don't uplift for such a low volume especially so lately in the Beta cycle. In addition, this issue first appeared in Firefox 16 so affected users can live with.

(In reply to Scoobidiver from comment #36) > Checking manually crash reports without duplicates in 19.0b3, I see only > four crashes in 19.0b3 which is very low. We don't uplift for such a low > volume especially so lately in the Beta cycle. > In addition, this issue first appeared in Firefox 16 so affected users can > live with. I never had this crash before 19.0beta. But I think I can wait three weeks before the next beta, so let's hope it stays at such a low volume. Thanks.