Bug 69929 - X locks up and eats the cpu randomly
Summary: X locks up and eats the cpu randomly
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: All Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 67218 79579
TreeView+ depends on / blocked
Reported: 2002-07-26 15:26 UTC by Nathan G. Grennan
Modified: 2007-04-18 16:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-22 09:04:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nathan G. Grennan 2002-07-26 15:26:21 UTC
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:

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

Comment 1 Mike A. Harris 2002-07-26 18:20:02 UTC
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.

Comment 2 Mike A. Harris 2002-08-06 06:55:25 UTC
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".

Comment 3 Nathan G. Grennan 2002-08-06 14:24:48 UTC
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?

Comment 4 Mike A. Harris 2002-08-20 07:28:30 UTC
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.

Comment 5 Tim Waugh 2002-08-28 11:06:12 UTC
chaos@okcforum.org: Has this happened since?  Did you manage to get a strace 
capture, or a backtrace from gdb?

Comment 6 Nathan G. Grennan 2002-08-28 13:27:57 UTC
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.

Comment 7 Tim Waugh 2002-08-28 13:40:15 UTC
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..)

Comment 8 Nathan G. Grennan 2002-08-28 14:02:05 UTC
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.

Comment 9 Mike A. Harris 2002-12-22 09:04:37 UTC
Unable to reproduce this on a Quadro 2 or Quadro 4 with rawhide XFree86
Dec 17 2002 snapshots.  Closing as fixed in RAWHIDE

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