Bug 426455 - xscreensaver crashes X, console frozen
xscreensaver crashes X, console frozen
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11 (Show other bugs)
4.5
i686 Linux
low Severity medium
: rc
: ---
Assigned To: X/OpenGL Maintenance List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-21 01:41 EST by gregrwm
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-10 10:32:27 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 gregrwm 2007-12-21 01:41:03 EST
Description of problem:
How reproducible:

a bug that forces me to reboot my server really gets my goat.  i lock the server
with xscreensaver to keep the kids from wreaking havoc on it.  numerous
times/week xscreensaver freezes, either by itself, or when hitting a key. 
usually i can get going (via ssh) by killing xscreensaver or just its
subprocess, but often X dies, sometimes the virtual terminal remains frozen, and
sometimes even chvt can't free the console, leaving me no option but reboot.

when X dies, that's either an X or a kernel problem, you can't just blame that
on xscreensaver.  a stuck console also implies bugs in the kernel console and/or
virtual terminal handlers.

this was happening before, but now seems to happen more often with, the latest
xorg packages.

after killing xscreensaver and/or the current xscreensaver subprocess, sometimes
merely ctl-alt-keypad-/ or ctl-alt-keypad-* will free it up.  meanwhile chvt
(via ssh) will sometimes be able to switch away from the frozen session, and
sometimes not.  sometimes the chvt will finally complete after xscreensaver is
finally killed.  often X will die, either right when xscreensaver is killed, or
perhaps not until receiving its next keystroke.  and sometimes after X has died,
the virtual terminal it was running in remains frozen, such that the next X
session lands in a new different virtual terminal, and if by habit i switch to
the stuck vt the keyboard is again dead to any further virtual terminal
switching, requiring to resort to chvt via ssh again.  but interestingly, after
a subsequent similar X death, the erstwhile frozen virtual terminal may once
again be responsive and host the next X session.

today the xscreensaver processes are gone after a mere kill, but, not as per
usual, chvt remains hung, with the frozen xscreensaver image still showing, X
wouldn't die with ctl-alt-backspace but remained stuck in a loop:

    Cpu(s): 1.0% us, 99.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si

      PID nFLT SHR VIRT SWAP RES %MEM TIME %CPU S COMMAND
     3707 18k 4980 90936 75m 13m 1.8 454:47 96.9 R X :0

only kill -KILL would stop X from consuming the CPU, but my console remains
stuck, chvt won't work, i don't know any way out other than reboot and that gets
my goat.

Steps to Reproduce:
1.  wait for xscreensaver to lock
2.  hit a key
3.  if xscreensaver freezes, try chvt (via ssh)
4.  find xscreensaver subprocess, kill -9
5.  if necessary kill -9 main xscreensaver process
6.  X may or may not die, vt may or may not freeze
7.  if frozen, chvt may or may not get you out
8.  if X is gone and chvt won't work, what's left other than reboot?

Version-Release number of selected component (if applicable):
kernel-2.6.9-55.EL
xorg-x11-6.8.2-1.EL.31
xscreensaver-4.18-5.rhel4.14
Comment 1 Ray Strode [halfline] 2007-12-21 09:43:22 EST
If you set the screensaver to blank screen do you still get lock ups?  There
have been reports of buggy 3D drivers causing this sort of thing when an OpenGL
screensaver gets played.
Comment 2 gregrwm 2007-12-23 00:37:27 EST
i'll try that.  and if you mean i should just do my best to avoid the bugs
that's fine, tho i'm happy to help with bug catching, i guess i expect a bug
that forces a linux reboot would be high on sombody's squashing list.
Comment 3 Ray Strode [halfline] 2007-12-23 10:24:50 EST
Hi,

I'm just suggesting a potential workaround, and an avenue to help debug the problem.
Comment 4 Matěj Cepl 2008-01-31 11:49:01 EST
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 attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

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

Thanks in advance.
Comment 5 Matěj Cepl 2008-03-03 15:56:00 EST
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 6 Matěj Cepl 2008-04-10 10:32:27 EDT
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

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