Bug 113002 - raise implemented via tkill breaks si_code
raise implemented via tkill breaks si_code
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: man-pages (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Eido Inoue
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-07 01:24 EST by Mike Perry
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.66-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-19 12:46:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Perry 2004-01-07 01:24:03 EST
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 03:53:26 EST
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 04:12:44 EST
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 11:12:21 EST
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 11:17:35 EST
With linuxthreads it actually will be SI_USER, but with NPTL SI_TKILL.
Comment 5 Eido Inoue 2004-02-19 12:46:05 EST
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.