Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?

[John Z. Bohach]

Hello,

It is unclear from the various documentions in the kernel and glibc what 
the proper behaviour should be for the case when a child process 
catches a SIGNAL (say for instance, SIGTERM), and then calls exit() 
from within its caught SIGNAL handler.

Since the exit() will cause a SIGCHLD to the parent, and the parent 
(let's say) has a SIGCHLD sigaction (SA_SIGINFO sa_flags set), should 
the parent's WIFSIGNALED(siginfo->si_status) be true?

To recap, the WIFSIGNALED section of the waitpid() manpage says:

WIFSIGNALED(status)
    returns true if the child process was terminated by a signal.

So the dilemna:  the child caught the signal, so it wasn't terminated by 
a signal, but rather its signal handler (let's say) called exit.

Furthermore:

WTERMSIG(status)
    returns the number of the signal that caused the  child  process
    to  terminate. This macro should only be employed if WIFSIGNALED
    returned true.

Observered behaviour with 2.6.20.6 is that is WIFSIGNALED(status) 
returns true (possibly incorrect), and furthermore, WTERMSIG(status) 
returns the exit(VALUE) VALUE from the child's exit() call, and not the 
SIGNAL (let's say SIGTERM that the child caught).  This may be correct, 
since the siginfo_t * si_status member is:

int      si_status; /* Exit value or signal */

but there's no clarity on which:  exit value or signal.  Since the child 
exited, I'm likely to assume exit status, which is current observed 
behaviour, but then, WIFSIGNALED(status) should be FALSE, which its not 
(observed with 2.6.20.6).

So could someone clarify the kernel's intent?

I can provide a short C program to illustrate above behaviour, if 
needed.  It also could be that I'm just misinterpreting the intent, 
which is why I'm not calling this a bug, despite a possible 
inconsistency in behaviour.

Thanks,
John


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/