Bug 417261 - random Xorg lockups when using FF
Summary: random Xorg lockups when using FF
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 8
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: pleaForReproductionFF3
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-09 15:28 UTC by Patrick C. F. Ernzer
Modified: 2018-04-11 10:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-25 12:39:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
tempertures and voltages of the box during a Xorg freeze (658 bytes, text/plain)
2007-12-09 15:29 UTC, Patrick C. F. Ernzer
no flags Details
xorg.conf of the affected box (938 bytes, text/plain)
2007-12-09 15:30 UTC, Patrick C. F. Ernzer
no flags Details
lspci -vvv of the affected box (10.62 KB, text/plain)
2007-12-09 15:30 UTC, Patrick C. F. Ernzer
no flags Details
syslog from shortly before the freeze and with the output of SysRq-t (179.18 KB, text/plain)
2007-12-09 15:35 UTC, Patrick C. F. Ernzer
no flags Details
SysRq-t output after issuing a chvt 1 (177.90 KB, text/plain)
2007-12-09 15:35 UTC, Patrick C. F. Ernzer
no flags Details
gdb output as requested (44.09 KB, text/plain)
2008-01-11 22:15 UTC, Patrick C. F. Ernzer
no flags Details

Description Patrick C. F. Ernzer 2007-12-09 15:28:37 UTC
Description of problem:
since F8 my machine will lock up Xorg randomly when using Firefox. Not quite 
sure if this should be filed under
 xorg-x11-server-Xorg
 xorg-x11-drv-ati
 firefox
but as so far I can only see this hang when actively using Firefox, I'll file 
under that component.

Version-Release number of selected component (if applicable):
 xorg-x11-server-Xorg-1.3.0.0-33.fc8
 xorg-x11-drv-ati-6.7.196-1.fc8
 firefox-2.0.0.10-2.fc8

How reproducible:
totally random but multiple times a day

Steps to Reproduce:
1. have a fully updated F8 box
2. be in X11 (gnome in case it matters
3. interact with firefox (enter text or click)
  
Actual results:
randomly Xorg will lock up as follows
  - display does not update
  - cursor still movable (I presume hardware cursor)
  - NumLock does not toggle LED
  - waiting up to 10 minutes still does not update display
  - ssh'ing to the machine works just fine, in a ssh session I will see
    (all commands run as root, after a sudo su -)
    + top shows X eating all CPU
    + pstack $(pidof Xorg) will just sit there
    + chvt 1 never returns and the display does not update (i.e. I still see 
X, not the expected VT 1)
    + issuing a 'shutdown -r now' works just fine but I see my frozen X until 
the machine actually resets

Expected results:
stable X

Additional info:
  - I ditched all proprietary Firefox plugins from my system, error persists
  - logs will follow

Comment 1 Patrick C. F. Ernzer 2007-12-09 15:29:52 UTC
Created attachment 282221 [details]
tempertures and voltages of the box during a Xorg freeze

Comment 2 Patrick C. F. Ernzer 2007-12-09 15:30:28 UTC
Created attachment 282231 [details]
xorg.conf of the affected box

Comment 3 Patrick C. F. Ernzer 2007-12-09 15:30:54 UTC
Created attachment 282241 [details]
lspci -vvv of the affected box

Comment 4 Patrick C. F. Ernzer 2007-12-09 15:35:09 UTC
Created attachment 282251 [details]
syslog from shortly before the freeze and with the output of SysRq-t

Comment 5 Patrick C. F. Ernzer 2007-12-09 15:35:49 UTC
Created attachment 282261 [details]
SysRq-t output after issuing a chvt 1

Comment 6 Patrick C. F. Ernzer 2007-12-09 15:41:44 UTC
some notes:
  $ rpm -qa|grep xorg|xargs rpm -V
  S.?.....   /usr/bin/Xorg
this seemed odd, so I did 
  $ sudo rpm -i --replacepkgs xorg-x11-server-Xorg-1.3.0.0-33.fc8.i386.rpm 
  $ rpm -V xorg-x11-server-Xorg
  ..?.....   /usr/bin/Xorg
yesterday. This morning the verify gave the same results bit now after another 
hang it reports
  S.?.....   /usr/bin/Xorg
again.


As to machine stability itself, apart from the freezes with FF and Xorg the 
machine is stable. I used my old UT2003 with the linux client to give it a 
graphics workout, worked just fine. The machine will also be stable when not 
interacting with firefox (it tends to run 24x7 and the only times I log out is 
on new kernel, when playing under the games loader (see below) or when there 
is a kernel update.

I also have that other OS installed to play World of Warcraft (which gives the 
machine a very thorough graphics workout as I play in 1600x122) and that is 
stable. Can't test anything else under Win though as WoW is the only installed 
application.

Comment 7 Patrick C. F. Ernzer 2007-12-09 16:01:52 UTC
agh, fat fingers, in Comment #6 I obviously meant 
  'but now' and not 'bit now'
  '1600x1200' and not '1600x122'

Comment 8 Patrick C. F. Ernzer 2007-12-09 17:43:55 UTC
an rpm -Va just showed
  S.?.....   /usr/lib/libGL.so.1.2
setting on NEEDINFO to self until I get the hang again after the
  rpm -i --replacepkgs mesa-libGL-7.0.1-7.fc8.i386.rpm
I just did

Comment 9 Patrick C. F. Ernzer 2008-01-07 23:36:35 UTC
It hung again, still no idea how to trigger or to debug it. But at least what I
mentioned in Comment #8 does not seem to be part of the problem. Removing the
NEEDINFO on me.

Comment 10 Matěj Cepl 2008-01-08 13:09:33 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please install firefox-debuginfo; in order to do this you have to enable
-debuginfo repository.

	yum install --enablerepo=\*debuginfo firefox-debuginfo

(if you use x86_64 firefox, install firefox-debuginfo.x86_64  package).

Then run firefox with a parameter -g. That will start firefox running inside of
gdb debugger. Then use command run and do whatever you did to make firefox
crash. When it happens, you should go back to the gdb and run

	(gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text
editor and attach the file to the bug as an uncompressed attachment.

In case the freeze happens when you are not running firefox inside of the
debugger already, you can connect with gdb to the existing firefox running with

    gdb --pid=$(pidof firefox-bin)

and then you can continue with thread apply all backtrace.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 11 Patrick C. F. Ernzer 2008-01-11 22:15:36 UTC
Created attachment 291427 [details]
gdb output as requested

here is the requested output

Comment 12 Patrick C. F. Ernzer 2008-01-11 22:18:02 UTC
oh and for completeness' sake

$ ps aux|grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
pcfe      3069  0.0  0.0      0     0 ?        Z    Jan08   0:00 [xrdb] <defunct>

no idea though if that was a zombie already before the freeze, it just caught my eye in the top output.

Comment 13 Matěj Cepl 2008-02-21 22:35:42 UTC
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

Comment 14 Matěj Cepl 2008-02-21 22:36:52 UTC
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.

Comment 15 Patrick C. F. Ernzer 2008-02-25 12:39:07 UTC
For other reasons (playing games) the box in question now has the closed source
ATI driver. As such I am unable to test (and the hang has not occurred since the
switch).

As the open source ATI driver is moving rapidly in a good direction, I will
close this bug for now with INSUFFICIENT_DATA and open a new one if the hang
re-occurs once I switched back to the open source ATI driver (or if I do see the
bug again under the current setup)


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