Description of problem: Occasionally I come back to my locked X session to find that it is not locked anymore. I ovserved it about a dozen times already. Version-Release number of selected component (if applicable): xlockmore-5.34-1.fc16.i686 How reproducible: Random Steps to Reproduce: Run xlock, then watch xlock run randon screensavers. When one of them SEGVs or FPEs, witness that therefore lock was broken w/o password. Possible duplicates: bug 57513, bug 10533. The gist of this bug is that since xlock has many different screensavers, it is unrealistic to expect that they all are bug-free (and will reamin so); therefore, it *must* be able to survive segfaulting in screensaver code. Please, let's not go down the road "it's a segfault in mode Foo, let's fix mode Foo". We will be back here when mode Bar will sigfault. I think a possible solution is to have two processes: a dumb (and therefore highly unlikely to segfault) parent process which babysits the child which does actual screensaver painting.
Of course you are right. But this is something you should discuss with upstream and not with me as it sounds more like a rewrite than packaging bug. I cannot help you and will therefore close this bug as CANTFIX.
Created attachment 647714 [details] Make xlock report correct exitcode if it dies from a signal
Reopening. Please accept this simple patch which would allow xlock's parent process to know that it crashed. I compile-tested it: http://koji.fedoraproject.org/koji/taskinfo?taskID=4703546 Before the patch, code was installing signal handlers for SIGSEGV and such, and if SIGSEGV happens, it emits some syslog messages and *exits with exit code 1*. The proper thing to do is to reset signal handlr to SIG_DFL and kill itself. This makes parent see the correct exitcode.
Thanks for the patch. I will include it. Have you submitted your patch upstream?
(In reply to comment #4) > Thanks for the patch. I will include it. Have you submitted your patch > upstream? Just sent it to xlock-develop.org, with subject: [PATCH] allow xlock's parent to know that it crashed
xlockmore-5.41-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc18
xlockmore-5.41-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc17
xlockmore-5.41-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc16
xlockmore-5.41-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/xlockmore-5.41-1.el6
Package xlockmore-5.41-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xlockmore-5.41-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18698/xlockmore-5.41-1.fc18 then log in and leave karma (feedback).
xlockmore-5.41-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
xlockmore-5.41-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
xlockmore-5.41-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
xlockmore-5.41-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.