Re: zombie with CLONE_THREAD

[Roland McGrath <roland@redhat.com>]

The reason strace hangs in that case is an strace bug.  strace is
blocking in a wait4 call on the specific PID of the zombie group leader,
which will never report until strace reaps the other non-leader thread
it is tracing.  But strace won't ever do that, because it's blocked
saying it only cares about the zombie leader's PID.  You should report
that bug in strace.  I pity the fool who agreed to maintain that unholy
pile of spaghetti--what a maroon!

The kernel bug is that when you kill strace, the non-leader zombie hangs
around and that keeps the zombie leader around too (which is the one
you'll see in ps).  The following patch fixes that for me.  I am not
100% confident that the locking dance required here doesn't create some
weird issue (and it certainly seems inefficient how many times the lock
is released and retaken in this sequence), but maybe 92% sure.


Thanks,
Roland


--- linux-2.6.7-mm4/kernel/exit.c.~1~	2004-06-30 16:29:06.000000000 -0700
+++ linux-2.6.7-mm4/kernel/exit.c	2004-06-30 18:55:36.000000000 -0700
@@ -618,9 +618,21 @@ static inline void forget_original_paren
 			reparent_thread(p, father, 0);
 		} else {
 			ptrace_unlink (p);
-			if (p->state == TASK_ZOMBIE && p->exit_signal != -1 &&
-			    thread_group_empty(p))
-				do_notify_parent(p, p->exit_signal);
+			if (p->state == TASK_ZOMBIE) {
+				if (p->exit_signal == -1) {
+					/*
+					 * This was only a zombie because
+					 * we were tracing it.  Now it should
+					 * disappear as it would have done
+					 * if we hadn't been tracing it.
+					 */
+					write_unlock_irq(&tasklist_lock);
+					release_task(p);
+					write_lock_irq(&tasklist_lock);
+				}
+				else if (thread_group_empty(p))
+					do_notify_parent(p, p->exit_signal);
+			}
 		}
 	}
 	list_for_each_safe(_p, _n, &father->ptrace_children) {