From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: The xscreensaver daemon process exits at random after the machine has been left idle for a long time, and usually after it has been activated and the screen is locked. Note that this is a SECURITY problem, because the screen will become unlocked by itself! There is no obvious predictability in when it will exit, I can let it run "locked" for many hours just fine, but often if left overnight the screensaver will have exited by morning. I was able to determine that the screensaver executable is exiting with an exit code of 1. But where do I look to get more diagnostic information? I did insure that dpms support in xscreensaver is disabled. Never saw this behavior under FC1 using the same hardware. Version-Release number of selected component (if applicable): xscreensaver-4.14-5 How reproducible: Sometimes Steps to Reproduce: 1. Lock screen, or let screen lock by itself after being left idle. Logged in as non-root user. 2. Wait (possibly several hours) 3. Screen should "unlock" by itself...the xscreensaver daemon will no longer be running. Actual Results: The xscreensaver daemon will terminate by itself. Expected Results: When locked, the xscreensaver daemon should not terminate by itself. Additional info: Kernel is SMP version: Linux version 2.6.6-1.435smp (bhcompile.redhat.com) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 SMP Mon Jun 14 09:31:56 EDT 2004 Graphics card is Matrox Millenium II. PCI:*(1:7:0) Matrox Graphics, Inc. MGA 2164W [Millennium II] rev 0, Mem @ 0xf8000000/24, 0xfe9dc000/14, 0xfe000000/23, BIOS @ 0xfea00000/16 The top portion of the ~/.xscreensaver file (without listing of screensaver programs): ----------------.xscreensaver----------- # XScreenSaver Preferences File # Written by xscreensaver-demo 4.14 for dem on Fri Jun 11 16:07:51 2004. # http://www.jwz.org/xscreensaver/ timeout: 0:05:00 cycle: 0:10:00 lock: True lockTimeout: 0:08:00 passwdTimeout: 0:00:30 visualID: default installColormap: True verbose: False timestamp: True splash: True splashDuration: 0:00:05 quad: False demoCommand: xscreensaver-demo prefsCommand: xscreensaver-demo -prefs nice: 10 memoryLimit: 0 fade: True unfade: False fadeSeconds: 0:00:03 fadeTicks: 20 captureStderr: True ignoreUninstalledPrograms:True font: *-medium-r-*-140-*-m-* dpmsEnabled: False dpmsStandby: 2:00:00 dpmsSuspend: 2:00:00 dpmsOff: 4:00:00 grabDesktopImages: False grabVideoFrames: False chooseRandomImages: True imageDirectory: /home/dem/backgrounds mode: random selected: 0 -----------------------------
Additional .xscreensaver settings (after programs: section)... pointerPollTime: 0:00:05 windowCreationTimeout:0:00:30 initialDelay: 0:00:00 sgiSaverExtension: True mitSaverExtension: False xidleExtension: True procInterrupts: True overlayStderr: True Does anybody want the whole contents of the programs: section too? Or is there some other information that would be useful?
First, I recently packaged the latest version of xscreensaver, so let's see if that fixes the problem. Would you mind installing the most recent xscreensaver rpm from rawhide? ftp://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/xscreensaver-4.16-1.i386.rpm In the event that that doesn't work, would you mind running these commands when you want to lock the screen for an extended period of time? killall xscreensaver xscreensaver -verbose -sync -nocapture >& ~/xscreensaver.log & xscreensaver-command -lock If it crashes while you are away could you attach ~/xscreensaver.log to the bug report? Thanks.
Okay, I've installed the 4.16.1 rawhide version and restarted my X session. We'll see what happens.
As a followup, the rawhide 4.16.1 version did not exit while running locked last night. This is the first night my screen has remained locked after upgrading to FC2. So this is a good sign that the bug might be fixed in the rawhide version.
That's good news. If you don't mind, please test it for a few more days. If you don't have any problems over those few days then I'll be optimistic and say the problem is fixed in rawhide. If there is ever a problem in the future you can reopen the bug, of course, and we can look into the problem more indepth.
I'm still running with rawhide 4.16.1, and everything is working perfectly. xscreensaver has never abruptly exited on it's own. So it certainly appears as if this new version has fixed the bug, whatever it was. I wish I knew better what the bug actually was. Because at least on my system it was very repeatable, and also posed a serious security threat if you relied on xscreensaver actually locking your screen.
Oops, it looks like xscreensaver 4.16.1 finally terminated on me last night after running fine for over two weeks. The exit code was '1'. I had started it a long time ago with the command, xscreensaver -verbose >~/.xscreensaver.log Since the log file is over 30000 lines long, I've attached an abbreviated copy of it with a lot of the middle section of the file cut out (still have the beginning and ending part of the log file). Quickly the last couple lines are: xscreensaver: 08:35:59: 0: killing pid 10423 (xjack) xscreensaver: 08:35:59: 0: child pid 10423 (xjack) terminated with SIGTERM. xscreensaver: 08:35:59: fading... xscreensaver: 08:36:01: fading done. xscreensaver: 08:36:01: 0: visual 0x25 (TrueColor, depth: 24, cmap: 256) xscreensaver: 08:36:01: 0: saver window is 0x8033f9. xscreensaver: 08:36:01: 0: destroyed old saver window 0x8033f6. xscreensaver: 08:36:01: 0: spawning "dangerball -root" in pid 10441.
Created attachment 101748 [details] log file of xscreensaver 4.16-1 with -verbose option Exited with 1 while system idle overnight.
I've had a similar problem. I'm running xscreensaver 4.16 (not the packaged version mentioned above, but my own packaged version..using the SPEC from 4.14 FC2). I'm randomly crashing and the logfile is showing: xscreensaver-getimage: target pixmap 0x2400008 unexpectedly deleted xscreensaver-getimage: target pixmap 0x2400008 unexpectedly deleted xscreensaver-getimage: target pixmap 0x2400008 unexpectedly deleted XIO: fatal IO error 10 (No child processes) on X server ":0.0" after 238502 requests (238501 known processed) with 0 events remaining. I can reproduce this everyday. I've run xscreensaver-demo with xteevee (which uses the xscreensaver-getimage) in preview mode for 2 days with no crash. I set xscreensaver to do a desktop capture AND/OR to get images from a directory. In either case Preview mode doesn't crash, but when I use xscreensaver to lock my terminal it will crash..and it is very random, sometimes lasting only a few hours, at most it has lasted 5 days (over July 4th holiday). I have tried multiple hacks (IE: screensavers) in preview mode and all of them are fine. However, EVERYTIME it has crashed in lock mode it was a module that uses xscreensaver-grabimage. I hope this helps someone.
I had it spontaneously quit on me again over the weekend (during which I was not using the computer). I see several parts where the following types of errors are output... xscreensaver: 12:39:21: 0: killing pid 30026 (twang) xscreensaver: 12:39:21: 0: child pid 30026 (twang) terminated with SIGTERM. xscreensaver: 12:39:21: 0: ungrabbing mouse (was 0x3f). xscreensaver: 12:39:21: 0: ungrabbing keyboard (was 0x3f). xscreensaver: 12:39:21: 0: unlocked mode switching. xscreensaver: 12:39:29: awaiting idleness. xscreensaver: 12:50:28: 0: unrecognised ClientMessage "_NET_CURRENT_DESKTOP" received xscreensaver: 12:50:28: 0: for window 0x3f (root) xscreensaver: 12:50:28: 0: unrecognised ClientMessage "_NET_DESKTOP_VIEWPORT" received xscreensaver: 12:50:28: 0: for window 0x3f (root) xscreensaver: 12:50:28: 0: unrecognised ClientMessage "_NET_ACTIVE_WINDOW" received xscreensaver: 12:50:28: 0: for window 0x24003f9 (Mozilla / mail:3pane) xscreensaver: 12:51:27: 0: unrecognised ClientMessage "_NET_CURRENT_DESKTOP" received xscreensaver: 12:51:27: 0: for window 0x3f (root) xscreensaver: 12:51:27: 0: unrecognised ClientMessage "_NET_DESKTOP_VIEWPORT" received xscreensaver: 12:51:27: 0: for window 0x3f (root) xscreensaver: 12:51:27: 0: unrecognised ClientMessage "_NET_ACTIVE_WINDOW" received xscreensaver: 12:51:27: 0: for window 0x2400073 (Mozilla / navigator:browser) ....and it continues like this for all the windows I have opened. Afterwards it seems to operate normally for a while. Finally another series of unrecognized ClientMessages appears finally before it terminates... xscreensaver: 13:57:05: 0: unrecognised ClientMessage "_NET_CURRENT_DESKTOP" received xscreensaver: 13:57:05: 0: for window 0x3f (root) xscreensaver: 13:57:05: 0: unrecognised ClientMessage "_NET_DESKTOP_VIEWPORT" received xscreensaver: 13:57:05: 0: for window 0x3f (root) xscreensaver: 13:57:06: 0: unrecognised ClientMessage "_NET_ACTIVE_WINDOW" received xscreensaver: 13:57:06: 0: for window 0x2611ff2 (gnome-terminal / Gnome-terminal) xscreensaver: 13:57:21: -1: unrecognised ClientMessage "_NET_WM_STATE" received xscreensaver: 13:57:21: -1: for window 0x400189 ((null) / (null)) xscreensaver: 13:57:21: -1: unrecognised ClientMessage "_NET_WM_STATE" received xscreensaver: 13:57:21: -1: for window 0x400189 ((null) / (null)) Is there anyway to make xscreensaver dump a core file? Or is it exiting willingly?
*** Bug 113987 has been marked as a duplicate of this bug. ***
Created attachment 106584 [details] stdout and stderr of xscreensaver with -verbose option
Created attachment 106585 [details] system call trace of xscreensaver process This output is manually annotated. Annotations marked with lines beginning with "***".
xscreensaver crashed again. This time it had only been active (and locked) for about 10 minutes. I have both the standard output/error captured, as well as a system call trace. Both of these output logs are attachments to this bug. Attached on 2004-11-12 11:26 and 2004-11-12 11:28 I'm still running FC2 with xscreensaver-4.16-1 xscreensaver exits are very rare, usually once or twice per week. But there is no apparent pattern to when it happens.
I finally saw xscreensaver exit by itself under FC3 (xscreensaver-4.18-4) over the weekend. I did not capture any debugging information though.
I had another occurance of coming into work after the weekend to find my screen completely unlocked again and the xscreensaver daemon not running. This is still FC3 i386 using xscreensaver-4.18-4. This bug is definitely very rare now (compared to when I first reported it), but it is nonetheless still a serious bug with security consequences. I don't know how to cause it to happen or I'd get a lot more information than I've already provided. I'm going to have to write an xscreensaver watchdog process I think, that restarts it if it ever crashes.
Hi Deron, I'm building xscreensaver packages into rawhide that might fix this. Would you mind testing them? They should show up tommorrow morning in rawhide as: xscreensaver-base-4.22-6 xscreensaver-extras-4.22-6 xscreensaver-gl-extras-4.22-6
Created attachment 117619 [details] Don't call unsafe functions in signal handlers Hi Jamie, This is the patch that I think may resolve this issue, if you want to apply it (or something similiar) upstream.
Sure, I can test it. However I should say that I haven't seen this bug in quite a few months. It was never easy to reproduce to begin with. I'm currently running FC3 with xscreensaver 4.18-4. Perhaps some of the other updates (kernel, glibc, etc) have been doing a good job of hiding this bug? Anyway I'll test it, at least to make sure it doesn't act worse. Deron
I fixed this in FC4 and rawhide a while ago. If you see this problem in FC3 again and want an update, ask, and I'll push one.