Description of problem: Running xscreensaver with the random screensaver option Version-Release number of selected component: xscreensaver-base-5.20-3.fc18 Additional info: backtrace_rating: 4 cmdline: xscreensaver -nosplash crash_function: kill_job executable: /usr/bin/xscreensaver kernel: 3.6.9-4.fc18.x86_64 remote_result: NOTFOUND uid: 1000 xsession_errors: Truncated backtrace: Thread no. 1 (10 frames) #4 kill_job at ../../driver/subprocs.c:442 #5 kill_screenhack at ../../driver/subprocs.c:1040 #6 saver_sighup_handler at ../../driver/windows.c:844 #8 __libc_waitpid at ../sysdeps/unix/sysv/linux/waitpid.c:31 #9 _unix_run_helper_binary at support.c:524 #10 _unix_blankpasswd at support.c:580 #11 pam_sm_authenticate at pam_unix_auth.c:152 #12 _pam_dispatch_aux at pam_dispatch.c:110 #13 _pam_dispatch at pam_dispatch.c:407 #14 pam_authenticate at pam_auth.c:34
Created attachment 661129 [details] File: backtrace
Created attachment 661130 [details] File: build_ids
Created attachment 661131 [details] File: cgroup
Created attachment 661132 [details] File: core_backtrace
Created attachment 661133 [details] File: dso_list
Created attachment 661134 [details] File: environ
Created attachment 661135 [details] File: limits
Created attachment 661136 [details] File: maps
Created attachment 661137 [details] File: open_fds
Created attachment 661138 [details] File: proc_pid_status
Created attachment 661139 [details] File: var_log_messages
Looks like something wrong happened on waitpid() (#8), then xscreensaver caught the signal and called abort() intentionally. Once switching to glibc for help.
waitpid sets errno when it returns -1. Looks like pam does not check or display the errno, which really is crucial to understanding why waitpid failed. If you figure out the errno, then you can figure out what went wrong and chances are the it's something to do with the program behaviour and not glibc.
(In reply to comment #13) > waitpid sets errno when it returns -1. Looks like pam does not check or > display the errno, which really is crucial to understanding why waitpid > failed. As far as I looked at the backtrace, it does not look like waitpid() returned -1, but looks like waitpid segfaulted (or something that causes signal raising) (or maybe I missed something). #7 <signal handler called> <=========================== No locals. #8 0x0000003b834baf3a in __libc_waitpid (pid=pid@entry=10945, stat_loc=stat_loc@entry=0x7fff3828fa2c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31 > If you figure out the errno, then you can figure out what went > wrong and chances are the it's something to do with the program behaviour > and not glibc.
Right, sorry, I didn't look carefully enough. Going by the handler that gets called, it looks like a SIGHUP, so it's again not anything to do with waitpid. I just checked /var/log/messages and it looks like xscreensaver was updated a few minutes ago. That might be relevant.
Back to xscreensaver as this really doesn't look like a glibc issue. The update of xscreensaver found in /var/log/messages seems highly relevant to me.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.