Bug 498500 - Firefox 3.5 causes RHEL 5.4 xorg to die with sig 11
Summary: Firefox 3.5 causes RHEL 5.4 xorg to die with sig 11
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-nv
Version: 5.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ben Skeggs
QA Contact: desktop-bugs@redhat.com
Depends On:
Blocks: 531112
TreeView+ depends on / blocked
Reported: 2009-04-30 18:58 UTC by Jay Turner
Modified: 2015-01-08 00:16 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-30 08:08:22 UTC
Target Upstream Version:

Attachments (Terms of Use)
Xorg.0.log from crash (53.04 KB, text/plain)
2009-04-30 18:58 UTC, Jay Turner
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0204 0 normal SHIPPED_LIVE xorg-x11-drv-nv bug fix and enhancement update 2010-03-29 12:27:12 UTC

Description Jay Turner 2009-04-30 18:58:02 UTC
Created attachment 341980 [details]
Xorg.0.log from crash

Description of problem:
I'm not entirely sure that Xorg is at fault, but seems pretty odd that pulling up a webpage in firefox would cause all of Xorg to fall over.  Granted we are talking about firefox 3.5b4 so there's a chance something is horked in FF which is causing this.  Anyway, attempting to pull the http://adorama.com with firefox-3.5b4 (downloaded from Mozilla's website) results in a sig11 for Xorg.

This is on a Sony VAIO running 2.6.18-142.el5 with an nVidia Corporation GeForce 9600M GT (rev a1).  I'll report an upstream bug against firefox as well.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Launch firefox-3.5b4
2. Pull up http://adorama.com
Actual results:

Expected results:
No Poof!

Additional Information:
I'm not able to reproduce on another x86_64 box with an Intel 965 card.

Comment 1 Jay Turner 2009-04-30 19:08:54 UTC
Another bit of information.  I switched to the vesa driver (everything else the same) and do not experience the crash.

Comment 2 Martin Stransky 2009-04-30 19:49:07 UTC
Can we get backtrace from firefox crash? With debuginfo packages installed please run "firefox -g -d gdb".

Comment 3 Jay Turner 2009-04-30 21:26:21 UTC
Sorry for being dense, but debuginfo for which?  xorg-x11-drv-nv or firefox?  If the former, will be glad, if the latter, that might take some more doing seeing as this is the upstream firefox binary (downloaded from mozilla) and therefore I doubt we have debuginfo.

Comment 4 Matěj Cepl 2009-05-15 23:41:50 UTC
And what about this guy? (that's from the end of Xorg.0.log where Xserver writes is backtraces)

0: /usr/bin/Xorg(xf86SigHandler+0x71) [0x494e01]
1: /lib64/libc.so.6 [0x338c830280]
2: /usr/lib64/xorg/modules/libfb.so(fbCompositeSrc_8888x8888mmx+0x265) [0x2afc89aa4175]
3: /usr/lib64/xorg/modules/libfb.so(fbComposite+0x5db) [0x2afc89a9365b]
4: /usr/lib64/xorg/modules/libxaa.so(XAAComposite+0x2ac) [0x2afc89ce494c]
5: /usr/bin/Xorg [0x51379d]
6: /usr/bin/Xorg [0x50fb54]
7: /usr/bin/Xorg [0x5032ef]
8: /usr/bin/Xorg(Dispatch+0x1ca) [0x449c9a]
9: /usr/bin/Xorg(main+0x44e) [0x4325ee]
10: /lib64/libc.so.6(__libc_start_main+0xf4) [0x338c81d974]
11: /usr/bin/Xorg(FontFileCompleteXLFD+0x231) [0x4318c9]

Fatal server error:
Caught signal 11.  Server aborting

Comment 5 Mark Gordon 2009-07-20 22:22:07 UTC
Are you still seeing this? I'm unable to reproduce the crash on 5.4.  Using GeForce 9600M GT, xorg-x11-drv-nv-2.1.12-6.el5, kernel-2.6.18-155.el5, and either current RHEL (3.0.11-2.el5_3) or upstream (3.5.1) firefox.  On the supposition that dynamic content might play a role, I reloaded the page 20 times (for each firefox version).

There has been a firefox-triggered crash fixed recently (Bug 448586), but that was a server fix, not a driver fix, and ought to have been an issue with any driver.

Comment 7 Jay Turner 2009-07-21 12:11:57 UTC
Still able to reproduce 100% of the time with both 3.5rc2 and 3.5.1 on my VAIO laptop ('nv' driver.)  The site works fine on the same hardware with 3.0.11-2.el5_3.  Note that on another machine (with the 'intel' driver) 3.5.1 works perfectly.  Again, since this is upstream 3.5.1 and not a package built by Red Hat, there might be something else going on.  I do find it interesting that the same tarball on two different x86_64 machines, one with nv and one with intel, results in totally different behavior.

Comment 8 Mark Gordon 2009-07-21 18:46:24 UTC
Correction: I was testing against a GeForce 6600 GT.  This bug appears to be very hardware-specific.

Comment 11 Jay Turner 2009-07-23 19:28:05 UTC
An additional note.  I dusted off a Lenovo W700 laptop today which has an nVidia card in it (01:00.0 0300: 10de:061e (rev a2).)  It's interesting that under the latest 5.4 trees (20090723.nightly) this card shows up as:

01:00.0 VGA compatible controller: nVidia Corporation Unknown device 061e (rev a2)

Anyway, when running the vesa driver, I can pull up the website with both firefox-3.0.12 and firefox-3.5.1.  No issues, all is well and happy.

However, if I restart using the nv driver, 3.0.12 works happily, but as with my VAIO, pulling up the website under firefox-3.5.1 causing X to crash.  This is a totally fresh installation . . . I rebooted, untarred the firefox tarball and ran the tests.  There's something very bad happening in the interaction between firefox-3.5.1 and the nv driver.

Comment 12 Cameron Meadors 2009-07-23 20:25:15 UTC
10de:061e looks like it is a Quadro FX 3700M (G92M)
GeForce 9600M GT is G96M

We have neither of those that we know of.  Very specific hardware.

Jay, are you doing anything other than loading the adorama.com url?  Does is crash immediately or is the page partially rendered before it crashes?

Comment 13 Jay Turner 2009-07-24 11:49:03 UTC
Just loading up the URL . . . it does sit there for a few moments before all of X goes *poof* but on both machines I can reproduce 100% of the time.  I'm still torn on this one seeing as it isn't a firefox we've built and appears to be very hardware specific.  The flip-side of the argument is I find it suspicious  that the combination of firefox-3.5.1 (or anything in the 3.5-series it appears) with our nv driver results in this crash.  3.5.1 with other drivers works just fine.  3.0.12 with the nv driver works.

As long as we have other cases where the 'nv' driver is working correctly with 3.5.1 (which appears to be the case from comment 5) then given that we don't have a root cause, we're kind of stuck.  I'm curious of testing on any other 'nv' hardware we happen to have floating around.

Comment 21 Philip Tellis 2009-11-19 02:42:08 UTC
I see the same problem but with an intel i810 driver.
Firefox-3.5.5 (from mozilla.org)
RHEL 5.3
Linux 2.6.18-92.1.22.el5
xorg-x11-server 1.1.1-48.52.el5

The backtrace looks like this:

0: /usr/bin/Xorg(xf86SigHandler+0x81) [0x80e5701]
1: [0xa02420]
2: /usr/lib/xorg/modules/libfb.so(fbCopyAreammx+0x1aa) [0x73163a]
3: /usr/lib/xorg/modules/libfb.so(fbCompositeCopyAreammx+0x66) [0x731776]
4: /usr/lib/xorg/modules/libfb.so(fbComposite+0x57b) [0x7224fb]
5: /usr/lib/xorg/modules/libxaa.so(XAAComposite+0x1db) [0x300eeb]
6: /usr/lib/xorg/modules/drivers/i810_drv.so(i830_xaa_composite+0x144) [0x4ca7f4]
7: /usr/bin/Xorg [0x815e026]
8: /usr/bin/Xorg [0x815a996]
9: /usr/bin/Xorg(CompositePicture+0x153) [0x8147b23]
10: /usr/bin/Xorg [0x814d95f]
11: /usr/bin/Xorg [0x814acd5]
12: /usr/bin/Xorg(Dispatch+0x19a) [0x808815a]
13: /usr/bin/Xorg(main+0x485) [0x806fab5]
14: /lib/libc.so.6(__libc_start_main+0xdc) [0xbbfe8c]
15: /usr/bin/Xorg(FontFileCompleteXLFD+0x1ed) [0x806edb1]

I believe bug 495733 and bug 476786 are similar

Comment 22 Philip Tellis 2009-11-19 02:52:46 UTC
I should add that I see it on this page as well:

It happens almost every time.  There are very few times when it does not crash.  The crash is triggered when I scroll to the bottom of the page.  It is preceded by the bottom of the screen getting a lot of screen garbage.

I tried switching to the vesa driver but then my screen alignment is just out of whack.

Comment 23 Ben Skeggs 2009-11-20 06:06:41 UTC
Philip, does adding: Option "XaaNoOffscreenPixmaps" to the device section of your xorg.conf resolve the issue?

Comment 25 Philip Tellis 2009-11-24 01:24:01 UTC
Ok, have been testing for about 30 minutes with the XaaNoOffscreenPixmaps option and have not had a crash yet.  Will test for another day before I'm sure.

Comment 29 Ben Skeggs 2009-12-17 02:10:52 UTC
MODIFIED xorg-x11-drv-nv-2.1.15-2.el5 is available in brew.

Comment 31 Philip Tellis 2010-01-08 00:11:33 UTC
Ok, still no crash.  The system has been running non-stop for over 6 weeks now.  I think it's safe to say that I no longer have this issue.

Comment 34 errata-xmlrpc 2010-03-30 08:08:22 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.