Messages in this thread | | | Date | Thu, 1 Jul 2004 00:06:51 -0700 | From | Roland McGrath <> | Subject | Re: zombie with CLONE_THREAD |
| |
> On Wed, 30 Jun 2004, Roland McGrath wrote: > > > > No, I am preserving the feature that the child doesn't go away in this case. > > ptraced threads always become zombies and let the ptracer see their exit > > notification and status value. That is the way we want it to stay. > > Umm.. This is not the "ptrace_list". This is the _regular_ child list.
The ptrace_list/ptrace_children list is the list of your natural children that someone else has stolen by tracing them. The "regular" child list is all your natural children that noone has stolen, plus the ones you are tracing. We are talking here about an element on your "regular" child list that is one you have stolen by tracing it, not a natural child. If it is a natural child, whether or not you are tracing it, this is not the case we have been addressing so far.
> Which means that a bad person can try to: > - have "normal" children that are self-reaping. > - _also_ have a self-reaping ptraced child. > > Now those _normal_ children may go away, no?
I think you are talking about this case:
#include <signal.h> #include <unistd.h> #include <sys/ptrace.h>
int main (void) { signal(SIGCHLD,SIG_IGN); switch (fork()) { case -1:perror("fork");return 2; case 0: ptrace(PTRACE_TRACEME, 0, (char *) 1, 0); _exit(2); default: sleep(2); return 0; } }
This program leaves a leaked zombie around. That is fixed by handling the case in reparent_thread where it possibly calls do_notify_parent in the same way as the forget_original_parent case. Not surprising, as both places have the same existing code to handle the same issue--and both overlook the same case. I've just tested a version of my prior patch that covers this case as well, and it works. I can give you either the lock-reacquiring version of that or the version based on the list-collection patch I just posted.
> .. since this information should be available anyway (we'll have woken up > the tracer, and the tracer will see that the child is gone by simply > seeing the ESRCH errorcode from ptrace).
When did you wake up the tracer? I don't see how that happened. If the tracer is blocked in a wait4 call and still has other live children, it stays blocked. Next time it wakes up for some other reason, it can poll via a wait4 or ptrace call for each specific thread it knows it was attached to and ascertain through ESRCH errors when one died. Having to do that sucks ass.
Thanks, Roland - 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/
| |