There is a subtle bug in the UNIX implementation for j.l.ProcessBuilder that could lead to zombies being accrued.
The underlying problem is that we fork, then exec; or posix_spawn, then exec. There are cases where we could report an IOException in ProcessBuilder.start() to the caller when the child process has actually been created successfully but where afterwards errors happened before the target exec(). This is by design.
In those cases, since we throw an IOException, caller will never reap the process. How could he, he has no Process. In those cases Java_java_lang_ProcessImpl_forkAndExec is responsible for reaping the child process. We don't do this for all error paths, though.
Affected are several paths when waiting for the liveness ping and when waiting for the exec error number.
The underlying problem is that we fork, then exec; or posix_spawn, then exec. There are cases where we could report an IOException in ProcessBuilder.start() to the caller when the child process has actually been created successfully but where afterwards errors happened before the target exec(). This is by design.
In those cases, since we throw an IOException, caller will never reap the process. How could he, he has no Process. In those cases Java_java_lang_ProcessImpl_forkAndExec is responsible for reaping the child process. We don't do this for all error paths, though.
Affected are several paths when waiting for the liveness ping and when waiting for the exec error number.
- relates to
-
JDK-8362257 (process) Remove aliveness-ping-workaround for older glibcs in POSIX_SPAWN mode
-
- Closed
-