detach() logic

[Denys Vlasenko]

On 06/19/2013 04:35 PM, Dmitry V. Levin wrote:
>>> PTRACE_DETACH should succeed and there should be no need to wait (and if
>>> PTRACE_DETACH failed, then the tracee is no more so strace is expected
>>> to wait for it).
>>
>> My point is, we *dont* wait if both DETACH and probing tkill(0)
>> fail with ESRCH. This might be wrong in some situations.
> 
> I suppose in that case, if TCB_STRACE_CHILD bit is set, strace should
> waitpid the tracee, expecting ECHILD or WIFSIGNALED status.

Ok, looks like *those* my fears were unfounded. At worst, we leak
(don't wait for) a zombie when "strace PROG" form is ^C-ed:
we detach() PROG, but not wait for it; but we exit immediately too.
So the zombie is reparented to init and init cleans it up.

If we detach() in "strace -p PID" situation, we don't,
and *shouldn't* eat exit status. I need to add a comment about it...

However, now I see another, very simple bug in detach():

                sigstop_expected = (tcp->flags & TCB_IGNORE_ONE_SIGSTOP);
                error = ptrace(PTRACE_DETACH, tcp->pid, 0, 0);

What if sigstop_expected == 1 (IOW: TCB_IGNORE_ONE_SIGSTOP is set)?

We will DETACH _before_ we eat and discard SIGSTOP.
After DETACH, we will do waitpid loop, see SIGSTOP,
and... try DETACH again! lol :(

Does it look like a real bug to you too?

-- 
vda