On Mon, 15 May 2023 19:55:45 GMT, Bernd <d...@openjdk.org> wrote: > Independent of the actual fix, it was mentioned that it can block listening > sockets, aren’t those close on exec? Also should a write and read timeout be > used in addition? At least to call the close descriptor code before retrying?
While the JDK opens files with `FD_CLOEXEC` by default, this is not the case for sockets. There have been attempts to fix this (see "[JDK-8207335: Use SOCK_CLOEXEC when creating sockets and channels](https://bugs.openjdk.org/browse/JDK-8207335)", [mailing list thread](https://mail.openjdk.org/pipermail/net-dev/2018-July/thread.html#11622)) but they never made it into mainline. Notice that this is usually only a problem if you fork from native code (e.g. in a JNI library). Otherwise the JDK takes care to close *all* file descriptors before `execvp()`ing a new process (see [this code in `childProcess()` in `childproc.c`](https://github.com/openjdk/jdk/blob/5763be726700be322de3bbaf345d80e11936b472/src/java.base/unix/native/libjava/childproc.c#L363-L369)). In this specific case the sockets were not closed because `jspawnhelper` blocked very early, *before* cleaning up the file descriptors in `childProcess()`. But that's now fixed with this PR :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551355679
