799544 - Crash with abort message: "X_FreeGC: BadGC (invalid GC parameter)" when opening about:support with Software Rasterizer - Mesa up to version 7.11

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[u279076]

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

Comment 1

[u279076]

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

Comment 2

[Scoobidiver (away)]

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

Comment 3

[u279076]

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?

Comment 4

[u279076]

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

Comment 5

[u279076]

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

Comment 6

[Scoobidiver (away)]

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

Comment 7

[Karl Tomlinson (:karlt)]

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.

Comment 8

[Alex Keybl [:akeybl]]

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

Comment 9

[u279076]

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.

Comment 10

[Matt Grimes [:Matt_G]]

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.

Comment 11

[Tony Mechelynck [:tonymec]]

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)

Comment 12

[Tony Mechelynck [:tonymec]]

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.

Comment 13

[Alex Keybl [:akeybl]]

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

Comment 14

[Tony Mechelynck [:tonymec]]

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

Comment 15

[Scoobidiver (away)]

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

Comment 16

[Tony Mechelynck [:tonymec]]

(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

Comment 17

[Scoobidiver (away)]

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

Comment 18

[Tony Mechelynck [:tonymec]]

(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?

Comment 19

[Scoobidiver (away)]

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

Comment 20

[Tony Mechelynck [:tonymec]]

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

Comment 21

[Robert Kaiser]

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

Comment 22

[Tony Mechelynck [:tonymec]]

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

Comment 23

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 24

[Scoobidiver (away)]

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

Comment 25

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: block the old Mesa 'Software Rasterizer' -- recommend LLVMpipe instead

Comment 26

[Benoit Jacob [:bjacob] (mostly away)]

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

Comment 27

[Scoobidiver (away)]

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

Comment 28

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 29

[Karl Tomlinson (:karlt)]

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.

Comment 30

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 31

[Tony Mechelynck [:tonymec]]

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

Comment 32

[Karl Tomlinson (:karlt)]

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.

Comment 33

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/df036783c5f3

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/df036783c5f3

Comment 35

[Aissen]

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.

Comment 36

[Scoobidiver (away)]

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

Comment 37

[Aissen]

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