Bug 113002 - raise implemented via tkill breaks si_code
Summary: raise implemented via tkill breaks si_code
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: man-pages
Version: 1
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eido Inoue
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-07 06:24 UTC by Mike Perry
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: 1.66-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-02-19 17:46:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mike Perry 2004-01-07 06:24:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114 Galeon/1.3.10

Description of problem:
It seems that raise is implemented as tkill, as evidenced by the fact
that for sigaction handlers, si_code is set to SI_TKILL for raise()ed
signals, when the manpages for sigaction indicate that raise should
cause si_code to be set to SI_USER instead.          
                                                                     
          
I would think that SI_USER is the more standards correct flag to set
for raise..

Version-Release number of selected component (if applicable):
glibc-2.3.2-101.1

How reproducible:
Always

Steps to Reproduce:
#include <stdio.h>
#include <signal.h>

void action_hdlr(int sig, siginfo_t *si, void *p)
{
    fprintf(stderr, "%d\n", si->si_code);
    exit(0);
}

int main(int argc, char **argv)
{
    struct sigaction sa;

    sa.sa_handler =0;
    sa.sa_flags = SA_RESTART | SA_SIGINFO;
    sigemptyset(&sa.sa_mask);
    sa.sa_sigaction = action_hdlr;
    sigaction(SIGILL, &sa, NULL);
    raise(SIGILL);
}


Actual Results:  -6 is printed, which is the si_code for SI_TKILL, not
SI_USER, as expected.

Expected Results:  SI_USER's value should be printed.. which is 0.

Additional info:

I haven't looked at the source for raise, but be wary just changing
that tkill.. It may exist for threads to be able to use raise() nicely..

Comment 1 Jakub Jelinek 2004-01-07 08:53:26 UTC
POSIX says that:
"If the implementation supports the Threads option, the effect of the raise() function shall be equivalent to calling:
pthread_kill(pthread_self(), sig);"
(otherwise kill(getpid(), sig);).
SI_USER's reason is written as "Signal sent by kill()."
and no si_code is mentioned for pthread_kill.
So I don't think POSIX mandates SI_USER in this case, but mandates
that it will be the same si_code as with pthread_kill
(which uses SI_TKILL as well).

Comment 2 Roland McGrath 2004-01-07 09:12:44 UTC
I concur.  The standard requires that pthread_kill result in an
implementation-defined value that is not equal to SI_USER or one of
the other specified values.  SI_TKILL is our implementation-defined
value for pthread_kill.  The standard further requires that raise
behave as if it were a call to pthread_kill.  Ergo, SI_TKILL is the
correct implementation-defined value.  Using SI_USER here would be in
violation of the standard.

Comment 3 Mike Perry 2004-01-07 16:12:21 UTC
Well can we get a documentation update for sigaction then? Becuase
those docs only mention SI_USER, and state that it is the si_code for
raise(), which is very misleading, and can lead developers to produce
buggy and non-portable software (which happened to me).

Comment 4 Jakub Jelinek 2004-01-07 16:17:35 UTC
With linuxthreads it actually will be SI_USER, but with NPTL SI_TKILL.

Comment 5 Eido Inoue 2004-02-19 17:46:05 UTC
fixed in 1.66 (look at the man page in both the regular section vs the
new POSIX section)


Note You need to log in before you can comment on or make changes to this bug.