> But I'm wondering the following situation though maybe it's not common:
> we've already traced a process A and its children, A should have
> TCB_FOLLOWFORK
> set. And then if A calls clone with CLONE_UNTRACED, I think strace will still
> allocate tcb for the new child which we don't trace.
>
> I'm sorry if I don't understand correctly.
You are quite right. The setting of the TCB_FOLLOWFORK bit got moved
around in a previous cleanup, and it now actually has no useful meaning at
all, it's essentially always set. But it is already tested in the places
we need for the related new purpose of this change. So I think the patch
below would indeed do the trick.
What do you think?
Thanks,
Roland
======
diff --git a/process.c b/process.c
index 8af960a..50f5ae8 100644
--- a/process.c
+++ b/process.c
@@ -796,7 +796,8 @@ int
internal_fork(struct tcb *tcp)
{
if (entering(tcp)) {
- if (!followfork)
+ tcp->flags &= ~TCB_FOLLOWFORK;
+ if (!followfork || (tcp->u_arg[ARG_FLAGS] & CLONE_UNTRACED))
return 0;
fork_tcb(tcp);
if (setbpt(tcp) < 0)
------------------------------------------------------------------------------
Automate Storage Tiering Simply
Optimize IT performance and efficiency through flexible, powerful,
automated storage tiering capabilities. View this brief to learn how
you can reduce costs and improve performance.
http://p.sf.net/sfu/dell-sfdev2dev
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel
