Reported as a part of rust-lang/rust#19120
The logic of rust-lang/rust@74fb798a20 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.
Also, panic! inside a loop over all children makes the logic simpler.
By not destructing the return values of Command::spawn() until
find_zombies() finishes, I believe we can conduct a slightly stricter
test.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
After the library successfully called fork(2), the child does several
setup works such as setting UID, GID and current directory before it
calls exec(2). When those setup works failed, the child exits but the
parent didn't call waitpid(2) and left it as a zombie.
This patch also add several sanity checks. They shouldn't make any
noticeable impact to runtime performance.
The new test case run-pass/wait-forked-but-failed-child.rs calls the ps
command to check if the new code can really reap a zombie. When
I intentionally create many zombies with my test program
./spawn-failure, The output of "ps -A -o pid,sid,command" should look
like this:
PID SID COMMAND
1 1 /sbin/init
2 0 [kthreadd]
3 0 [ksoftirqd/0]
...
12562 9237 ./spawn-failure
12563 9237 [spawn-failure] <defunct>
12564 9237 [spawn-failure] <defunct>
...
12592 9237 [spawn-failure] <defunct>
12593 9237 ps -A -o pid,sid,command
12884 12884 /bin/zsh
12922 12922 /bin/zsh
...
Filtering the output with the "SID" (session ID) column is a quick way
to tell if a process (zombie) was spawned by my own test program. Then
the number of "defunct" lines is the number of zombie children.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
