Bug 746 - sigaction SA_RESETHAND flag does not set SA_NODEFER
Summary: sigaction SA_RESETHAND flag does not set SA_NODEFER
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.4
: P2 minor
Target Milestone: ---
Assignee: GOTO Masanori
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-16 10:00 IST by Sebastien Decugis
Modified: 2006-12-02 22:54 IST (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Testcase for the bug 746 (1.91 KB, application/octet-stream)
2005-02-16 10:02 IST, Sebastien Decugis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Decugis 2005-02-16 10:00:34 IST
The Single Unix Specification (aka POSIX) requires that when the SA_RESETHAND
flag is set in sigaction, the function behaves as if SA_NODEFER is already set.

This is not the case with glibc 2.3.4 (NPTL enabled) and kernel 2.6.11-rc2-bk3.
Comment 1 Sebastien Decugis 2005-02-16 10:02:42 IST
Created attachment 409 [details]
Testcase for the bug 746

Usage:
    ./bug_sigaction X
Where X is:
 O  to have the SA_NODEFER flag set explicitely
 1  to have only SA_RESETHAND
According to POSIX, the behavior should be the same.

I get:
$ ./bug_sigaction 0
Both SA_NODEFER and SA_RESETHAND are set.
Test PASSED

$ ./bug_sigaction 1
Only SA_RESETHAND is set -- SA_NODEFER is implicit.
Test bug_sigaction.c FAILED: Signal was masked when SA_NODEFER was implicitely
set
Comment 2 Ulrich Drepper 2005-09-27 00:52:27 IST
sigaction in libc is only a thin wrapper around the system call.  Any such
change should happen in the kernel.
Comment 3 Michael Kerrisk 2006-09-21 05:12:57 IST
Sebastien,

A while back I also noticed this point where Linux seems to devaite from
POSIX, or vice versa.  I hadn't got round to testing other implementations,
but now I've run your program on some other systems:

FreeBSD 6.1: same results as Linux.

Solaris 8: same results as Linux.

HP-UX 11: passes both tests, according to your program.

Since POSIX generally standardizes existing practice, I'm
not sure what this all means.  Have you tried your program
on some other systems?

Cheers,

Michael
Comment 4 Sebastien Decugis 2006-09-21 07:47:06 IST
Hi Michael,

At the time of the testing I was concerned about the conformance of the NPTL
implementation to the POSIX standard. I may have tried the tests on a couple of
other implementations, but I did not keep track of these.

Even though POSIX standardizes existing practices, this happens at the time when
the POSIX standard is being defined. Once it has been written, I think an
implementation must conform to what is written, or it is not fully
POSIX-conformant. Anyway if you feel the POSIX standard is not suitable on this
point, there are mailing lists to submit changes and fix to the standard.

Best regards,
seb.
Comment 5 Michael Kerrisk 2006-10-05 03:38:31 IST
Hi Sebastien,

Some further tests (by someone I communicated with) show that
Solaris 10 and Unixware 2 also don't comply.

I have mentioned the widespread non-conformance to someone
at The Open Group.  Something may change as a result.  I will
try to remember to post here.

Cheers,

Michael
Comment 6 Michael Kerrisk 2006-12-02 22:54:04 IST
I had some communication with someone in the opengroup.  It looks like (i.e.,
this is not 100% decided yet) the standard is going to be changed to permit
either behaviour (i.e., the currently specified behaviour, or the actual
behaviour of Linux and many other implementations).