Bug 874484

Summary: xlock exits on segfault, unlocking the screen
Product: [Fedora] Fedora Reporter: Denys Vlasenko <dvlasenk>
Component: xlockmoreAssignee: Adrian Reber <adrian>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: adrian, rhel
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-08 04:29:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Make xlock report correct exitcode if it dies from a signal none

Description Denys Vlasenko 2012-11-08 10:04:33 UTC
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.

Comment 1 Adrian Reber 2012-11-08 11:10:34 UTC
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.

Comment 2 Denys Vlasenko 2012-11-19 12:21:56 UTC
Created attachment 647714 [details]
Make xlock report correct exitcode if it dies from a signal

Comment 3 Denys Vlasenko 2012-11-19 12:27:04 UTC
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.

Comment 4 Adrian Reber 2012-11-19 15:41:13 UTC
Thanks for the patch. I will include it. Have you submitted your patch upstream?

Comment 5 Denys Vlasenko 2012-11-20 16:25:46 UTC
(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

Comment 6 Fedora Update System 2012-11-21 12:38:28 UTC
xlockmore-5.41-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc18

Comment 7 Fedora Update System 2012-11-21 12:40:43 UTC
xlockmore-5.41-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc17

Comment 8 Fedora Update System 2012-11-21 12:41:45 UTC
xlockmore-5.41-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/xlockmore-5.41-1.fc16

Comment 9 Fedora Update System 2012-11-21 12:43:15 UTC
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

Comment 10 Fedora Update System 2012-11-21 20:52:21 UTC
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).

Comment 11 Fedora Update System 2012-12-08 04:29:39 UTC
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.

Comment 12 Fedora Update System 2012-12-08 21:06:27 UTC
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.

Comment 13 Fedora Update System 2012-12-09 05:56:16 UTC
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.

Comment 14 Fedora Update System 2012-12-09 06:01:00 UTC
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.