Bug 77835 - xscreensaver crashes system
xscreensaver crashes system
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
athlon Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-14 03:30 EST by Michael A. Peters
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael A. Peters 2002-11-14 03:30:31 EST
Description of Problem:
xscreensaver crashes my linux system

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

How Reproducible:
For me - very reproducable

Steps to Reproduce:
1. Install WindowMaker
2. Use this .xinitrc to start wmaker:
#!/usr/bin/bash

# set numlock
/usr/local/bin/xnumlock &

# start Xscreensaver
/usr/X11R6/bin/xscreensaver &

# start gnome-panel
/usr/bin/gnome-panel &

# start rhn applet
/usr/bin/rhn-applet-gui &

#start windowmaker
exec /usr/bin/wmaker

Actual Results:
When the system is left idle, sooner or later the entire system will freeze.
Machine will not even be pingable.

When commenting out xscreensaver in above .xinitrc (or using KDE which doesn't
by default use xscreensaver) system is completely stable.

I went > week uptime in KDE no crash.
Can't go very long in either gnome or WindowMaker UNLESS i disable xscreensaver.


Expected Results:
xscreensaver should not crash machine.

Additional Information:
RH 8.0 up2date on all patches.
Stock kernel (update applied from up2date)
Vid Card : AGP VooDoo3
Snd Card : none (except linux non functional mobo onboard)
PCI Cards :
1) Hardware US Robotics 56k modem (not being used currently)
2) 10/100 NIC (I think tulip driver)
3) second 10/100 NIC (I think also tulip driver)

CPU : 900 MHz AMD Athlon
Mobo : I think its a Asus. Not positive, though.
Mem : 128MB

This box was rock solid stable in Red Hat 7.0-beta (over 1 year uptime) and Red
Hat 7.2
Comment 1 Michael A. Peters 2002-11-14 03:58:04 EST
Added Comment -
I haven't seen anything in the logs to indicate what it might be (I looked- it
all looked normal to me, and then the new boot messages from my reboot), but
before I go to bet- I'll turn xscreensaver back on, and have a cli script
echoing the time to a log file.

Theoretically that will make it easy for me to identify exactly where to look in
the logs beyond question (I assume that if the machine is not even pingable that
it has crashed and any script will die)

--Could the gnome crash bug that is being reported really be this?
Comment 2 Bill Nottingham 2002-11-14 12:55:34 EST
Probably an issue with the DRI/DRM drivers.
Comment 3 Michael A. Peters 2002-11-15 00:53:16 EST
The system didn't crash on me - but it did dump me down back into console.

I went out for a bit - here are the messages that are relevant:

*blah about modprobe and sound-slot*
Nov 14 13:40:33 mpetershomenetwork modprobe: modprobe: Can't locate module
sound-slot-0
Nov 14 13:40:34 mpetershomenetwork modprobe: modprobe: Can't locate module
sound-service-0-3
Nov 14 20:52:51 mpetershomenetwork gconfd (mpeters-3178): Received signal 1,
shutting down cleanly
Nov 14 20:52:59 mpetershomenetwork gconfd (mpeters-3178): Exiting
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): starting (version
1.2.1), pid 18746 user 'mpeters'
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at
position 0
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readwrite:/home/mpeters/.gconf" to a writable config source at position 1
Nov 14 21:32:33 mpetershomenetwork gconfd (mpeters-18746): Resolved address
"xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at
position 2
Nov 14 21:32:36 mpetershomenetwork xinetd[18749]: warning: can't get client
address: Transport endpoint is not connected
Nov 14 21:32:57 mpetershomenetwork su(pam_unix)[18782]: session opened for user
root by (uid=999)

-=-
At 20:52 when gconf-d exited I wasn't home.
At 9:32 when gconf-d started is when I found myself in console and started X.

I don't know if this is the same bug, but if it is- then it is a local physical
security issue, as the screensaver requires a password to exit but this dumped
me into the console I started X from.
Comment 4 Michael A. Peters 2002-11-15 00:54:14 EST
note - when I said 9:32 read 21:32 ;)
Comment 5 Michael A. Peters 2002-11-19 07:29:55 EST
It's crashed twice for me now - not just X shutting down - nothing about gconf-d
in the logs on the hard crashes.

So I don't know if the gconf-d problem where X abnormally exits and the hard
crash are the same thing.

For now I'll just be patient and not run xscreensaver and hope Red Hat 8.1 (the
.1 releases are always better) will make it all better.
Comment 6 Gilles Berger Sabbatel 2002-11-25 08:45:41 EST
I don't know if it is related, but I have a similar problem with a laptop.

The chipset is an I 830M

When a screensaver using OpenGL is started, the display first freeze (does not
even respond to CTRL-Alt-Del), but still respond to network : a kill of the 
screensaver or the X server does not solve the problem.  Eventualy, the system
freeze completely and does not even respond to network.

The same thing happen with an other OpenGL application such as "tuxracer".
I usualy use the Gnome desktop, and did not try with an other environment.

This problem did not happen with RH 7.3, and does not happen on other hardware 
(ATI radeon, for example).
Comment 7 Martin J. Kehoe 2003-04-20 12:09:39 EDT
Dear Ladies & Gentlemen: 
The Red Hat 9.0 OS locks up if the screensaver is on after a certain length of
time.   A guess is fifteen (15) minutes.   I did not load KDE when I loaded Red
Hat 8.0.  Some time (a few days) After Red Hat 9.0 was installed, I finally
managed to install KDE (I have not yet figured out how to "restart" KDE - I am a
mouse 'point and click' user, not a programmer).  
The screen did show the following message (yellow on a black background):
xscreensaver: 10:51:48: -1: unrecognized client message :NET_WM-STATE" received
xscreensaver: 10:51:47: -1: for window 0x4009bc ((null)/(null))
The two lines above were repeated once (as typed above).
Please tell me how to fix this opportunity (point and click). 
Martin J. Kehoe 
From: mjkehoe@bulloch.net
Comment 8 Michael A. Peters 2003-04-20 17:54:16 EDT
This bug was opened by me.
I'm not sure what the problem other people are having, but mine was a bad cpu,
and not a bug with Red Hat. I know this because when the cpu abruptly died - I
used the same hard drive in a different box w/ via chipset and same rating cpu
and same video card and there were no problems ever again.

I'm guessing that other people with this problem should try to run memtest86 for
several hours (start it before you go to bed) - as memtest86 will likely have
errors if the problems if the cpu and/or ram has problems.

I really recommend this - with me, I only had problems in XScreensaver at first
- for weeks, everything else was fine. Then occasionally I would get I/O errors
when compiling. But rarely. Then oggenc would occasionally core dump and
occasionally lock the system. Then one day the system would not boot at all.

So if you have a problem with XScreensaver - while it might be a bug, I would
recommend running a diagnostic like memtest86 for awhile to make sure its not
hardware.
Comment 9 Bugzilla owner 2004-09-30 11:40:11 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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