<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 14, 2022 at 6:40 PM Martin Doucha <<a href="mailto:mdoucha@suse.cz">mdoucha@suse.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13. 02. 22 5:28, Li Wang wrote:<br>
> diff --git a/lib/newlib_tests/test_children_cleanup.sh b/lib/newlib_tests/test_children_cleanup.sh<br>
> index 4b4e8b2f0..ec1a0d4fe 100755<br>
> --- a/lib/newlib_tests/test_children_cleanup.sh<br>
> +++ b/lib/newlib_tests/test_children_cleanup.sh<br>
> @@ -13,7 +13,13 @@ if [ "x$CHILD_PID" = "x" ]; then<br>
> elif ! kill -s 0 $CHILD_PID &>/dev/null; then<br>
> echo "TPASS: Child process was cleaned up"<br>
> exit 0<br>
> +elif grep -q -E "Z|zombie" /proc/$CHILD_PID/status; then<br>
> + echo "TPASS: Child process was in zombie state"<br>
> + exit 0<br>
<br>
We're in a race condition here either way so reading the status procfile<br>
after checking whether the process still exists can result in failure<br>
even when the child was properly killed. I wrongly believed that<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Ah yes. It is still possible to complete the zombie reclaim just before doing the grep. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
`kill -s 0` would fail when the target process is a zombie because the<br>
manpage vaguely suggests that (see the description of ESRCH errno in the<br>
kill(2) manpage) but it turns out I was wrong again.<br>
<br>
I'll send a fix myself later today.<br></blockquote><div><br></div></div><div class="gmail_default" style="font-size:small">Thanks, I look forward to a better solution.</div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>