Lines Matching refs:zombie

14658 	This is yet another case of zombie leader detection making things a
14681 	was zombie, due to the exec), and then adding the leader back when it
15564 	exit event for the zombie leader too, i.e., making GDBserver respect
15570 	the event to GDBserver core.  For the zombie leader scenario
112874 	Somehow, above, GDB re-added the zombie leader back before printing
135094 …reads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
135095 …reads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
135096 	      [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
135111 	   failure can be explained by the LWP becoming zombie, and swallows the
135118 	 - check_zombie_leaders detects that the leader is zombie and deletes
135162 …reads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
135163 …reads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
135164 	      [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
139424 	Re-add zombie leader on exit, gdbserver/linux
139427 	In summary, the current zombie leader detection code in linux-low.cc
139429 	check_zombie_leaders finds that the leader is now zombie via checking
139448 	Re-add zombie leader on exit, gdb/linux
139449 	The current zombie leader detection code in linux-nat.c has a race --
139451 	finds that the leader is now zombie via checking /proc/PID/status,
139476 	become zombie.
139489 	threads immediately when the zombie leader is detected, assuming there
139492 	become zombie _before_ the kernel kills all other threads.  Waitpid in
139502 	the non-leader threads.  Then, if we are left with only the zombie
141236 	counting it as dead would cause a zombie leak - A process in such a