lkml.org 
[lkml]   [2001]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Children first in fork
In article <9bn90l$anp$1@penguin.transmeta.com> you write:
> You're probably even better off just intercepting the fork, turning it
> into a clone, and setting the CLONE_PTRACE option.

Actually it is not that simple. The child process will be traced by its
father, not the tracing program. The father must detach from its child
in order to allow the tracing program to attach to the child, and then
you have again the race condition: the child will be untraced for some
time.

The trick is to modify the return address of the call so that the child
and the father loop on the syscall. This way, you can make the father:

-- modify the child so that the child will send itself a SIGSTOP when
released
-- detach itself from the child
(-- if the child is scheduled, it stops itself)
Then the tracing process can attach to the child and handle the
situation.

I have some code almost running, doing that. Well, it works, but with
strange bugs in some occasions. I am still sorting these out. It is
utterly tricky, anyway.


--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:26    [from the cache]
©2003-2011 Jasper Spaans