Re: [ptrace] please review follow fork/exec changes

On 02/13/2012 07:28 AM, Konstantin Belousov wrote:
> I looked at the orphan.patch.
>
> Am I right that the orphans are the real childs of the process which
> are temporarily reparented to the debugger ? Whatever they are, a comment
> should be added to proc.h describing what does it mean.

Done.


>
> Please provide me with a test case that demonstrates the issue
> solved by the change.

<ftp://ftp.springdaemons.com/soft/>I attached 2 source files that compile into separate binaries. scescx should be able
The problem I'm trying to solve is to allow a parent to collect it's child exit status while we're following its child. Gdb detaches from the parent upon successful switch-over from parent to child. At this point due to re-parenting the parent loses the child to gdb and if it's in a wait() it'll get a return status that it has no children to wait for.

>
> The new LIST_FOREACH(&q->p_orphans) body is copy/pasted, together
> with the comments, from the LIST_FOREACH(&q->p_children). Can the
> common code be moved into some function ?

Moved the common code into a function. Didn't have time to test though.

>
> Shouldn't there be some assertion in proc_reparent() for the case when
> we remove child from the orphans list, that the child is no longer
> debugged ?

Hmm... Not sure I understand...

>
> Why in proc_reparent(), in the case of P_TRACED child, you do
> PROC_UNLOC/PROC_LOCK ?

No idea how it ended up like that... I'll clean it up.

>
> It seems that now wait4(2) can be called from the real (non-debugger)
> parent first and result in the call to proc_reap(), isn't it ? We would
> then just reparent the child back to the caller, still leaving the
> zombie and confusing debugger.
When either gdb or the real parent gets to proc_reap() the process wouldn't get destroyed, it'll get caught by the following clause:
     if (p->p_oppid && (t = pfind(p->p_oppid)) != NULL) {

and the real parent with get the child back into the children's list while gdb will get it into the orphan list. The second time around when proc_reap() is entered, p->p_oppid will be 0 and the process will get really reaped. Does it make sense? And proc_reparent() attempts to keep the orphan list clean and not have the same entries and the list of siblings.

The idea is to keep the real parent alive ling enough  to collect the statuc of the child running under gdb.