Red Hat Bugzilla – Bug 69929
X locks up and eats the cpu randomly
Last modified: 2007-04-18 12:44:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020720
Description of problem:
When using nv driver, and Mozilla with Xft1 support X will randomly lock up and
start eatting the cpu. It seems to happen when scrolling, tho I am not sure. I
can ssh into the machine just fine. If you try to shutdown -r it doesn't finish
and totally locks up. If I kill HUP X it will stop eatting all of the cpu, but
the machine will still totally lock up if I try to shutdown -r. Ctrl-alt-f1
doesn't work, and none of the lock keys/leds work. It can take up to a few days
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure X to use the nv driver
3. Start Mozilla
4. Wait a few days
Actual Results: X will lock up
Expected Results: X to not ever lock up
Video card: Geforce2 MX
Disable anti-aliasing for now, that is the only workaround.
Nvidia has been made aware of the problem, and hopefully has or will
fix it for the next XFree86 release. If a bugfix is made known for
this problem, I will apply it to a future build.
I've just been informed the problem I was refering to above was
fixed in XFree86 4.2.0 already, so the problem you're experiencing
must be different.
After re-evaluating your report, it sounds to me like Mozilla
is leaking pixmaps or somesuch. If you strace the X server from
a remote ssh session, what is the X server doing when the problem
Also, what does the output of top show, when sorted with the M key
(sort by memory)?
Please also attach your X server log and /var/log/messages from after
a crash. Also supply the output of "uname -a".
Ok, I will get a build of Mozilla+Xft1 built and start using it again. Like I
said above this can take days to happen. Can I modify gdm to start X in a screen
Bugs that take days to reproduce, unfortunately are very hard to
debug/troubleshoot. As such, they tend to also be lower priority
than bugs that are more easily reproduceable.
The best way to debug X, is to log in to the console locally in
runlevel 3 as root. Then run: gdb XFree86
Similar for strace, etc.
You need to use gdb-xfree86 from ftp://people.redhat.com/mharris/gdb-xfree86
as regular gdb can't debug the X server.
I also strongly recommend reporting this problem to firstname.lastname@example.org,
where Mark Vojkovich from Nvidia can see it. He's quite helpful, and
it is entirely possible a patch could materialize that could be
potentially incorporated into rawhide and into our final release.
email@example.com: Has this happened since? Did you manage to get a strace
capture, or a backtrace from gdb?
No, since it is such a pain in the ass to debug. The final straw for me was when
mharris said I had to run X as root while debugging. As long as it takes to see
this that would be just too much hassle. So I have reverted back to Mozilla
without Xft1 support.
If you have another console available, you don't have to run X as root. You
can attach gdb to X while your X session is running as a user. Like this:
[start X as normal]
root# ps axf
[look for X pid]
root# gdb /usr/X11R6/bin/XFree86 6926 (or whatever)
Or, even if your machine isn't networked, you can run 'strace -p 6926 2>log'
as root on a VT, and look at the log file afterwards. (If you have enough disk
space for it..)
Would it be good enough to run X from inside screen that logs all output to a
file and it be accessible across the network? This is what I was doing before.
Unable to reproduce this on a Quadro 2 or Quadro 4 with rawhide XFree86
Dec 17 2002 snapshots. Closing as fixed in RAWHIDE