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 to happen. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Configure X to use the nv driver 2. startx 3. Start Mozilla 4. Wait a few days Actual Results: X will lock up Expected Results: X to not ever lock up Additional info: 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 occurs? 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 with strace?
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 xpert@xfree86.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.
chaos@okcforum.org: 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) (gdb) c 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