JDK-8324979 : Can the JDWP process management file descriptor handling be more robust?
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2024-01-30
  • Updated: 2025-10-07
  • Resolved: 2025-10-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8364312 - debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file
Relates :  
JDK-8324668 - JDWP process management needs more efficient file descriptor handling
Description
jThis is a follow up to JDK-8324668.

Try to make this code as robust as possible:

#1 - what to do with errors from "close()"?

#2 - do we even want to bother with the fallback code if opendir() fails, or should opendir() be expected to never fail and therefore any failure should be fatal.

#3 - would “fcntl(d, F_SETFD, 1)” be of use here?
Comments
I do not like this part: /* We're trying to close all file descriptors, but opendir() might * itself be implemented using a file descriptor, and we certainly * don't want to close that while it's in use. We assume that if * opendir() is implemented using a file descriptor, then it uses * the lowest numbered file descriptor, just like open(). So * before calling opendir(), we close a couple explicitly, so that * opendir() can then use these lowest numbered closed file * descriptors afresh. */ close(from_fd); /* for possible use by opendir() */ close(from_fd + 1); /* another one for good luck */ The "assume" part concerns me. Also the extra call for "good luck". Again, using “fcntl(d, F_SETFD, 1)” might side step all of these issue by closing the file descriptors after launching the child AND letting the os handle all of it.
31-01-2024
The other thing that might need investigation is whether we should switch to using posix_spawn() like the ProcessImpl (the implementation behind the java.lang.ProcessBuilder.start() API) does by default. posix_spawn seems to have been used to avoid certain issues with fork() - for example https://bugs.openjdk.org/browse/JDK-5049299. The ProcessImpl_md.c for unix in the JDK has some information of these child process launch mechanisms as a code comment https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/ProcessImpl_md.c#L53. The usage of posix_spawn() in the ProcessImpl appears a bit more involved where it launches a jspawnhelper https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L136 before execing the child process https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/ProcessImpl_md.c#L106
31-01-2024
For opendir() and close() failures, rather the LOG_MISC() I'd suggest using error_message(), which will exit if errorexit=y is used, or tty_message() or print_message(). You can also use ERROR_MESSAGE(), which is pretty much the same as error_message(), except it also logs the error to the log file. I don't like LOG_MISC because basically no one is ever going to see the message. MISC logging is off by default, and even if on only goes to the logfile, not stdout or stderr.
30-01-2024
My initial thought here is that we might benefit from relaying on the os to do a better job of closing the file descriptors. Maybe the os has an optimized path for doing this? It shifts the responsibility from us doing the closing of file descriptors to the os?
30-01-2024
From "man close": Most of the descriptors can be rearranged with dup2(2) or deleted with close() before the execve is attempted, but if some of these descriptors will still be needed if the execve fails, it is necessary to arrange for them to be closed if the execve succeeds. For this reason, the call “fcntl(d, F_SETFD, 1)” is provided, which arranges that a descriptor will be closed after a successful execve; the call “fcntl(d, F_SETFD, 0)” restores the default, which is to not close the descriptor.
30-01-2024