Description of problem: xscreensaver daemon aborts immediately after launch. Version-Release number of selected component (if applicable): 5.06-1.fc8 How reproducible: Start xscreensaver on my system. Possibly the issue is due to my having two screens but NOT spanning, they're separate heads / protocol screens. Also possible that Xrandr features are being relied on that aren't fully supported in the F8 version of the X server. Just guessing, though. Steps to Reproduce: 1. Push an inessential experimental xscreensaver update to a stable distro. 2. ... 3. PROFIT! Actual results: It aborts, like so: [bill@bill ~]$ xscreensaver -sync -verbose -log log.txt xscreensaver: 12:05:00: logging to file log.txt Aborted Expected results: Should not fail. Additional info: Attaching the log file in a moment ...
Created attachment 312461 [details] Log output from xscreensaver
CCing to jwz.
Need a stack trace.
Yeah, will try to capture a trace in a moment ...
Pasting in here 'cause it's fairly short #0 0x0011e402 in __kernel_vsyscall () #1 0x00149690 in raise () from /lib/libc.so.6 #2 0x0014af91 in abort () from /lib/libc.so.6 #3 0x08051b65 in saver_exit (si=0xbf945244, status=-1, dump_core_reason=0x806aff8 "because of synchronous X Error") at ../../driver/windows.c:904 #4 0x0804d5c8 in saver_ehandler (dpy=0x99a6430, error=0xbf944de8) at ../../driver/xscreensaver.c:336 #5 0x0030e71e in _XError (dpy=0x99a6430, rep=0x99ae160) at XlibInt.c:2905 #6 0x00316263 in _XReply (dpy=0x99a6430, rep=0xbf944f10, extra=0, discard=0) at xcb_io.c:417 #7 0x0066f77b in XRRGetScreenResources (dpy=0x99a6430, window=0) at XrrScreen.c:81 #8 0x080538b3 in update_screen_layout (si=0xbf945244) at ../../driver/screens.c:386 #9 0x0804d893 in main (argc=Cannot access memory at address 0x6 ) at ../../driver/xscreensaver.c:784 #10 0x00136390 in __libc_start_main () from /lib/libc.so.6 #11 0x0804bbc1 in _start ()
As the error appears within XRRGetScreenResources I'm assuming this is probably a bug in libXrandr or in the X server rather than xscreensaver, feel free to reassign it if you like.
I don't know how RootWindow(dpy,i) is returning 0, unless you have both A) multiple real X screens (ScreenCount > 0) and B) RANDR stuff happening at the same time. I wasn't even sure that was possible. But I can't tell whether that's the case because it died before it was able to print out a debug log of your screens and geometry. Also, update_screen_layout does not call XRRGetScreenResources, so that stack trace is garbled. I suspect you're not compiled with -g.
I do indeed have multiple real X screens, and was running from a terminal on screen 1, although I wouldn't have expected that to matter ... Anyway, it appears that randr_scan_monitors() has been inlined, which gcc likes to do these days; repeated backtrace is the same. I double checked that I have the correct version of the debuginfo package installed. #0 0x0011e402 in __kernel_vsyscall () #1 0x00149690 in raise () from /lib/libc.so.6 #2 0x0014af91 in abort () from /lib/libc.so.6 #3 0x08051b65 in saver_exit (si=0xbf86f264, status=-1, dump_core_reason=0x806aff8 "because of synchronous X Error") at ../../driver/windows.c:904 #4 0x0804d5c8 in saver_ehandler (dpy=0x973e450, error=0xbf86ee08) at ../../driver/xscreensaver.c:336 #5 0x0030e71e in _XError (dpy=0x973e450, rep=0x9746188) at XlibInt.c:2905 #6 0x00316263 in _XReply (dpy=0x973e450, rep=0xbf86ef30, extra=0, discard=0) at xcb_io.c:417 #7 0x0066f77b in XRRGetScreenResources (dpy=0x973e450, window=0) at XrrScreen.c:81 #8 0x080538b3 in update_screen_layout (si=0xbf86f264) at ../../driver/screens.c:386 #9 0x0804d893 in main (argc=Cannot access memory at address 0x6 ) at ../../driver/xscreensaver.c:784 #10 0x00136390 in __libc_start_main () from /lib/libc.so.6 #11 0x0804bbc1 in _start ()
Lemme know if there's anything else I can do (have the exploded source here, can add printf()s or whatever tomorrow).
Please build and run "test-randr" from the xscreensaver-5.06/driver/ src. Also, xdpyinfo.
Also, by "real X screens" I mean you address them with $DISPLAY :0.0 and :0.1. Just because you have mutliple monitors doesn't mean you have real X screens. That's kind of the whole point of RANDR/Xinerama.
(In reply to comment #10) > Please build and run "test-randr" from the xscreensaver-5.06/driver/ src. > Also, xdpyinfo. > Hi, Bill: For now I created a subpackage "xscreensaver-tests" which contains some binaries for testing like "/usr/libexec/xscreensaver/test-randr" or so. Would you try this from the following? http://kojipkgs.fedoraproject.org/packages/xscreensaver/5.06/1.fc8.1/ xdpyinfo is in xorg-x11-utils package. For Jamie: Do you want me to ship test-* binaries under driver/ directory for Fedora xscreensaver rpms from next time?
No, they're separate protocol screens (.0 and .1) - I have two cards, and this way I get DRI on both heads, hence nice fast 3d screensavers :o)
Created attachment 312539 [details] Output from test-randr The "event" I sent it was just changing the refresh rate on one screen, hence the lack of apparent change.
Created attachment 312575 [details] patch Ok, I think I just fixed this -- but the other folks weren't getting crashes. (Congratulations, I think you're the first person ever to try and use real multi-screen on a system with randr 1.2 available...)
Jamie: you wouldn't believe how many people tell me "don't do that" ;o) Thanks for patch, building now ...
... fixed, thanks.
Good news, thanks!
> For Jamie: > Do you want me to ship test-* binaries under driver/ directory for Fedora > xscreensaver rpms > from next time? Nah, they're almost never needed...
xscreensaver-5.06-2.fc9 has been submitted as an update for Fedora 9
xscreensaver-5.06-2.fc8 has been submitted as an update for Fedora 8
It seems the update packages are already pushed. If the bug still exists, please feel free to reopen this bug. Thank you, Bill and Jamie. Closing.