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
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
