BadDrawable crash when doing any OpenGL stuff with software Mesa
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
firefox (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
0 down vote favorite
share [g+] share [fb] share [tw]
I've Firefox version 10.0.2 on Xubuntu 11.10. Every time I go to either www.gnome-look.org or www.xfce-look.org the browser crashes, even when running it in safe mode with all the add-ons disabled.
Please let me know if can provide some other output from my system to resolve this. Otherwise, shall I switch to Chromium, which never crashes but collects all my browsing data and such?
This is the version of the package that the system uses:
firefox:
Installed: 10.0.2+
Candidate: 10.0.2+
Version table:
*** 10.0.2+
500 http://
500 http://
100 /var/lib/
7.
500 http://
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: firefox 10.0.2+
ProcVersionSign
Uname: Linux 3.0.0-16-generic i686
NonfreeKernelMo
AddonCompatChec
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
ApportVersion: 1.23-0ubuntu4
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC0D0p: encrypt 1441 F...m pulseaudio
BuildID: 20120216101208
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0x58340000 irq 45'
Mixer name : 'Realtek ALC272X'
Components : 'HDA:10ec0272,
Controls : 17
Simple ctrls : 10
Channel: release
Date: Tue Feb 21 05:20:44 2012
ForcedLayersAccel: False
IfupdownConfig:
auto lo
iface lo inet loopback
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
IpRoute:
default via 192.168.1.1 dev eth2 proto static
169.254.0.0/16 dev eth2 scope link metric 1000
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.4 metric 2
Plugins:
Shockwave Flash - Lib=libflashpla
Gnome Shell Integration - Lib=libgnome-
IcedTea-Web Plugin (using IcedTea-Web 1.1.3 (1.1.3-1ubuntu1.1)) - Lib=IcedTeaPlug
VLC Multimedia Plug-in - Lib=libvlcplugi
ProcEnviron:
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=
RunningIncompat
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/18/2010
dmi.bios.vendor: Acer
dmi.bios.version: V1.29
dmi.board.
dmi.board.name: Aspire one
dmi.board.vendor: Acer
dmi.board.version: V1.29
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.
dmi.modalias: dmi:bvnAcer:
dmi.product.name: Aspire one
dmi.product.
dmi.sys.vendor: Acer
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #6 |
I only see this under Linux. I should also mention that I am using osmesalib as my graphics driver does not support opengl.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #7 |
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://
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.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #8 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #9 |
(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_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #10 |
(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".
In Mozilla Bugzilla #589546, Timeless-bemail (timeless-bemail) wrote : | #11 |
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.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #12 |
@ 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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #13 |
(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.
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #14 |
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.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #15 |
@ 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_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #16 |
(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_
> 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.
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #17 |
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 Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #18 |
(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 Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #19 |
(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).
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #20 |
So, the fact that you're getting this crash only when using your hardware-
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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #21 |
Looks like a similar report with better stack but on Arch Linux.
(Reporter is on FC12.)
bp-fe6605a3-
swrast_dri.so suggests Mesa.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #22 |
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 GLContextProvid
PRBool MakeCurrent()
{
Bool succeeded = sGLXLibrary.
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...
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #23 |
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 CreateOffScreen
nsRefPtr<
if (xsurface-
return nsnull;
}
GLXPixmap glxpixmap = sGLXLibrary.
if (glxpixmap == 0) {
return nsnull;
}
Do you see something wrong there?
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #24 |
The man page,
http://
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[] = {
0
};
So maybe a patch would be to set this bit (patch coming).
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #25 |
Created attachment 468291
add GLX_WINDOW_BIT
This patch adds GLX_WINDOW_BIT, as the glXCreatePixmap suggests is needed...
In Mozilla Bugzilla #589546, Joe-drew (joe-drew) wrote : | #26 |
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.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #27 |
Joe: the original reporter thought he was running OSMesa, but realized in comment 12 that it was actually using his ATI driver.
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #28 |
(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_
I will try this patch tonight to see if it fixes my original issue.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #29 |
(In reply to comment #19)
> The man page,
>
> http://
>
> ... 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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #30 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #31 |
(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.
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #32 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #33 |
(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/
(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 Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #34 |
(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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #35 |
(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/
> (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/
(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/
(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
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #36 |
@ 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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #37 |
What might actually be more useful and possibly easier to produce than a stack is a log from xtrace: http://
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #38 |
(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://
>
> 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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #39 |
(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://
>
> 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_
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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #40 |
I build Debian's 1.1.0 version from here:
http://
http://
(I don't recall much in the debian patch for that.)
and run with
.../install/
35 comments hidden Loading more comments | view all 115 comments |
In Mozilla Bugzilla #589546, octoploid (cryptooctoploid) wrote : | #76 |
Unfortunately I've hit the same issue, please see:
Bug 616416
http://
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #77 |
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.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #78 |
I mean, just the X crash part of it. I'll notify this bug.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #79 |
*** Bug 621699 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #80 |
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=0x7f1f3263
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=0x7f1f3263
#1 0x00007f1f38b6ecbf in handle_error (dpy=0x7f1f3263
#2 0x00007f1f38b6ed06 in handle_response (dpy=0x7f1f3263
#3 0x00007f1f38b6f2b0 in _XReply (dpy=0x7f1f3263
#4 0x00007f1f38b6a9b9 in XSync (dpy=0x7f1f3263
#5 0x00007f1f38b6ab7b in _XSyncFunction (dpy=0x7f1f3263
#6 0x00007f1f38b71847 in _XPrivSyncFunction (dpy=0x7f1f3263
#7 0x00007f1f38b4a87a in XCreateGC (dpy=0x7f1f3263
#8 0x00007f1f3438b742 in XCreateDrawable (base=0x7f1efbd
#9 driCreateDrawable (base=0x7f1efbd
#10 0x00007f1f3438baa7 in driFetchDrawable (gc=0x7f1f09e91300, glxDrawable=
#11 0x00007f1f3438b26a in drisw_bind_context (context=
#12 0x00007f1f343694c1 in MakeContextCurrent (dpy=0x7f1f3263
#13 0x00007f1f3e9b197c in mozilla:
#14 0x00007f1f3d79b4f7 in mozilla:
#15 0x00007f1f3e9b18b1 in mozilla:
#16 0x00007f1f3e9b15ff in mozilla:
#17 0x00007f1f3e9b0dd2 in mozilla:
#18 0x00007f1f3e9b133f in mozilla:
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #81 |
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_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #82 |
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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #83 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #84 |
(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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #85 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #86 |
(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
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #87 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #88 |
(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
> OpenGL version string: 2.1 Mesa 7.9
> OpenGL shading language version string: 1.20
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #89 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #90 |
(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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #91 |
(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 Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #92 |
(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 Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #93 |
(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_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #94 |
(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 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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #95 |
(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.
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #96 |
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:
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #97 |
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 :)
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #98 |
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_
Jan 14 09:59:22 waglaptop kernel: [14228.737427] radeon 0000:01:05.0: r600_packet3_
Jan 14 09:59:22 waglaptop kernel: [14228.737430] [drm:radeon_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #99 |
(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.
In Mozilla Bugzilla #589546, Scoobidiver (scoobidiver) wrote : | #100 |
It is #3 top crasher on Linux in 4.0b9 for the last week.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #101 |
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 Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #102 |
(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 Mozilla Bugzilla #589546, Thierry Bonifas (stebs) wrote : | #103 |
(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://
bp-ee16aea2-
Other WebGL Demos mostly work.
Are runs/crashes with tryserver-builds still wanted? (if yes, new url needed)
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #104 |
@ Stebs:
please file new bugs with that; this bug report is getting too big. Please include the output of glxinfo | egrep -i vendor\
In Mozilla Bugzilla #589546, Scoobidiver (scoobidiver) wrote : | #105 |
It is #2 top crasher on Linux in 4.0b11.
In Mozilla Bugzilla #589546, Bjacob (bjacob) wrote : | #106 |
Bug 632969 should fix this except for people who explicitly define MOZ_GLX_
In Mozilla Bugzilla #589546, Bill-wg9s (bill-wg9s) wrote : | #107 |
(In reply to comment #101)
> Bug 632969 should fix this except for people who explicitly define
> MOZ_GLX_
I would expect this is people who explicitly define the environment variable in order to test and comment in bug 624593.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #108 |
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.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #109 |
Now that bug 616416 is fixed, Gallium on llvmpipe also runs into this.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #110 |
This is now caught by the simple glxtest:
(gdb) p /x *(xCreateGCReq*
$17 = {reqType = 0x37, pad = 0x0, length = 0x4, gc = 0x3200004, drawable = 0x3200002, mask = 0x0}
(gdb) bt
#0 _XError (dpy=0x7ffff6d7
at /var/tmp/
#1 0x00007ffff0463eff in handle_error (dpy=0x7ffff6d7
at /var/tmp/
#2 0x00007ffff0463f46 in handle_response (dpy=0x7ffff6d7
in_XReply=1) at /var/tmp/
#3 0x00007ffff04644f0 in _XReply (dpy=0x7ffff6d7
extra=<value optimized out>, discard=<value optimized out>)
at /var/tmp/
#4 0x00007ffff045fbf9 in XSync (dpy=0x7ffff6d7
at /var/tmp/
#5 0x00007ffff045fdbb in _XSyncFunction (dpy=0x7ffff6d7
at /var/tmp/
#6 0x00007ffff0466a87 in _XPrivSyncFunction (dpy=0x7ffff6d7
at /var/tmp/
#7 0x00007ffff043fa7a in XCreateGC (dpy=0x7ffff6d7
values=0x0) at /var/tmp/
#8 0x00007fffec51b1a2 in XCreateDrawable (base=0x7ffff6d
drawable=<value optimized out>, modes=0x7ffff6d
#9 driCreateDrawable (base=0x7ffff6d
modes=
#10 0x00007fffec51b507 in driFetchDrawable (gc=0x7ffff6d4b360, glxDrawable=
at dri_common.c:373
#11 0x00007fffec51acca in drisw_bind_context (context=
draw=1, read=20) at drisw_glx.c:266
#12 0x00007fffec4f8f01 in MakeContextCurrent (dpy=0x7ffff6d7
gc_user=<value optimized out>) at glxcurrent.c:265
#13 0x00007ffff236cae9 in glxtest () at /home/karl/
#14 0x00007ffff236ccb0 in fire_glxtest_
#15 0x00007ffff23569c2 in XRE_main (argc=1, argv=0x7fffffff
at /home/karl/
#16 0x0000000000401ec7 in do_main (
exePath=
argv=
#17 0x000000000040205d in main (argc=1, argv=0x7fffffff
at /home/karl/
(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...
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #111 |
The "failed to create drawable" bug is
https:/
also reported at
https:/
and looks quite likely to be the cause of the failure in MakeCurrent.
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #112 |
*** Bug 667439 has been marked as a duplicate of this bug. ***
110 comments hidden Loading more comments | view all 115 comments |
Norwegian Wood (norwegianwood10) wrote : | #1 |
- AlsaDevices.txt Edit (410 bytes, text/plain; charset="utf-8")
- BootDmesg.txt Edit (49.8 KiB, text/plain; charset="utf-8")
- Card0.Amixer.values.txt Edit (2.2 KiB, text/plain; charset="utf-8")
- Card0.Codecs.codec.0.txt Edit (12.2 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (3.3 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.8 KiB, text/plain; charset="utf-8")
- Extensions.txt Edit (844 bytes, text/plain; charset="utf-8")
- IpAddr.txt Edit (685 bytes, text/plain; charset="utf-8")
- IwConfig.txt Edit (236 bytes, text/plain; charset="utf-8")
- Locales.txt Edit (292 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (11.7 KiB, text/plain; charset="utf-8")
- PciMultimedia.txt Edit (587 bytes, text/plain; charset="utf-8")
- PciNetwork.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- Prefs.txt Edit (631 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.4 KiB, text/plain; charset="utf-8")
- PulseSinks.txt Edit (2.2 KiB, text/plain; charset="utf-8")
- PulseSources.txt Edit (3.4 KiB, text/plain; charset="utf-8")
- RfKill.txt Edit (128 bytes, text/plain; charset="utf-8")
- Themes.txt Edit (132 bytes, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (149.8 KiB, text/plain; charset="utf-8")
Micah Gersten (micahg) wrote : | #2 |
Thank you for reporting this to Ubuntu. Could you please follow the instructions at https:/
Changed in firefox (Ubuntu): | |
status: | New → Incomplete |
Norwegian Wood (norwegianwood10) wrote : | #3 |
This is the ID that mozilla gives for this crash:
ID: e3627ae9-
109 comments hidden Loading more comments | view all 115 comments |
In Mozilla Bugzilla #589546, Karlt (karlt) wrote : | #113 |
*** Bug 717663 has been marked as a duplicate of this bug. ***
108 comments hidden Loading more comments | view all 115 comments |
Micah Gersten (micahg) wrote : Re: BadDrawable crash when doing any OpenGL stuff | #4 |
Thank you for the updated information. Based on the crash report, I've associated this bug with its upstream counterpart. The upstream comments should be imported into Launchpad soon for you to follow. Please report any other issues you may find.
summary: |
- firefox crashes in www.gnome-look.org and www.xfce-look.org + BadDrawable crash when doing any OpenGL stuff |
Changed in firefox (Ubuntu): | |
importance: | Undecided → Medium |
status: | Incomplete → Triaged |
summary: |
- BadDrawable crash when doing any OpenGL stuff + BadDrawable crash when doing any OpenGL stuff with software Mesa |
Changed in firefox: | |
importance: | Unknown → Critical |
status: | Unknown → Confirmed |
109 comments hidden Loading more comments | view all 115 comments |
Karl Tomlinson (bugs+launchpad) wrote : | #114 |
I very much doubt that X_CopyArea: BadMatch in Flash Player would be related to CreateGC: BadDrawable from OpenGL.
Why is Flash Player running in the browser process?
Changed in firefox: | |
importance: | Critical → Undecided |
status: | Confirmed → New |
penalvch (penalvch) wrote : | #115 |
Norwegian Wood, thank you for reporting this and helping make Ubuntu better. However, your crash report is missing. Please follow these instructions to have apport report a new bug about your crash that can be dealt with by the automatic retracer. First, execute at a terminal:
cd /var/crash && sudo rm * ; sudo apt-get update && sudo apt-get -y upgrade && sudo apt-get -y install firefox-dbg && sudo service apport start force_start=1
If you are running the Ubuntu Stable Release you might need to enable apport in /etc/default/apport and restart.
Now reproduce the crash, then open your file manager, navigate to your /var/crash directory and open the crash report you wish to submit.
If this fails you will have to open a terminal and file your report with 'ubuntu-bug /var/crash/
gksudo gedit /etc/apport/
and comment out the line:
'problem_types': ['Bug', 'Package'],
by changing it to:
# 'problem_types': ['Bug', 'Package'],
Save, close, and try to file the crash report again via:
ubuntu-bug /var/crash/
Please follow https:/
I'm closing this bug report since the process outlined above will automatically open a new bug report which can then dealt with more efficiently.
Thank you for your understanding.
Helpful bug reporting tips:
https:/
no longer affects: | firefox (Ubuntu) |
affects: | firefox → firefox (Ubuntu) |
Changed in firefox (Ubuntu): | |
status: | New → Invalid |
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-1b12921008 22