RFR: 8307990: jspawnhelper must close its writing side of a pipe before reading from it
Volker Simonis
simonis at openjdk.org
Wed May 17 13:06:51 UTC 2023
On Mon, 15 May 2023 19:55:45 GMT, Bernd <duke at 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
More information about the core-libs-dev
mailing list