Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered?

From: Keno Fischer
Date: Tue Sep 13 2016 - 17:59:05 EST

Hi Oleg,

I have another obscure ptrace question which seems somewhat related,
so let me ask it here.
Consider this:

static int sigchld_counter = 0;
void sigchld_handler(int sig) {

int main(void) {
signal(SIGCHLD, sigchld_handler);

pid_t child;
if (0 == (child = fork())) {
assert(0); // Should never be continued

// Wait until stopped
int status;
pid_t wret = waitpid(child, &status, __WALL | WSTOPPED);
assert(wret == child);
assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP);
assert(sigchld_counter == 1);

// Now PTRACE_SEIZE the child
long err = ptrace(PTRACE_SEIZE, child, NULL, (void*)PTRACE_O_TRACESYSGOOD);
assert(err == 0);

// Make sure that didn't cause a notification
wret = waitpid(child, &status, __WALL | WSTOPPED | WNOHANG);
assert(wret == 0);
assert(sigchld_counter == 1);

I wouldn't have expected the PTRACE_SEIZE to generate another
SIGCHLD/be waitable again,
(the last two assertions fail).
Is that supposed to happen? If so, I'd like to update the man page to
mention this behavior, but
I wanted to check with you first.


On Tue, Aug 23, 2016 at 11:34 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> On 08/18, Keno Fischer wrote:
>> On Thu, Aug 18, 2016 at 12:23 PM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>> >
>> > And you if you get PTRACE_EVENT_STOP and WSTOPSIG() == SIGTTIN after
>> > PTRACE_INTERRUPT, you know that the tracee did not report the "new"
>> It seems possible to remember whether or not we injected a stopping
>> signal and if so the next PTRACE_EVENT_STOP is a group-stop, otherwise
>> a PTRACE_INTERRUPT stop. Currently what I do is the other way around,
>> after issuing PTRACE_INTERRUPT, the first (if any) of the next two
>> stops that is a PTRACE_EVENT_STOP get interpreted as a
>> PTRACE_INTERRUPT stop. I haven't thought through this fully yet, so I
>> can't give you a concrete example I worried about, it just seems
>> fragile compared to just checking whether WSTOPSIG() == SIGTRAP.
> Yes, I see your point. And to remind, I was confused too.
> Perhaps we can add another THIS_SIGNAL_WAS_ALREADY_REPORTED bit, but
> you know, I'd prefer to avoid another subtle change in behaviour. You
> can never know if it is "safe" or not when it comes to ptrace, perhaps
> some application already relies on this WSTOPSIG().
> Oleg.