This is a discussion on RE: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race - Kernel ; > What do you mean by "extra"? There is a SIGTRAP sent after execve > completes when ptraced, even when PTRACE_SYSCALL is not being used. > So for an execve that succeeds under PTRACE_SYSCALL, there is a > ptrace_notify at ...
> What do you mean by "extra"? There is a SIGTRAP sent after execve
> completes when ptraced, even when PTRACE_SYSCALL is not being used.
> So for an execve that succeeds under PTRACE_SYSCALL, there is a
> ptrace_notify at syscall entry, then a SIGTRAP queued (i.e., not seen
> by ptrace if blocked), then a ptrace_notify at syscall exit. If
> that's what's happening (including the blocked SIGTRAP not being seen
> by the ptracer, i.e. strace), then there is no mystery (and no bug).
This might not be the same bug ... but I do have a definite 100%
reproducible bug (latest git kernel, old version of strace (4.5.15-1.el4.1))
$ strace -o logit -f make
in any directory where make is actually going to have to do some
work. You'll see that the command hangs after make outputs the
first action that it will take. Looking at the stack traces of
the 3 processes involved it seems that make forked, the child
stopped in ptrace waiting for some action from strace, but strace
isn't woken from its sleep in wait().
Backtrace of pid 6442 (strace)
Backtrace of pid 6443 (make)
Backtrace of pid 6444 (make)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/