On Mon, 2 Mar 2026 11:19:41 GMT, Volker Simonis <[email protected]> wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix builds for glibc < 2.34 > > src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 55: > >> 53: * file-descriptor errors. We may have no other way of >> 54: * communicating those errors to the parent. */ >> 55: #define ERR_FD_SETUP 245 > > Why do we need this? It seems that it isn't checked anywhere. Also, because > `exit()` only returns the most significant byte as exit code, we might return > `0` (i.e. "*success*") if the offending file descriptor happens to be 11. I used this during debugging of the MacOS implementation, and found it useful. This is only used for file descriptors 0..4, hard-wired. This is used when we detect problems with file descriptor setup (fd 0..4) at startup, which would always be either a programmer error or a problem with the OS/libc. `shutItDown` is useless since it confers no information at all - just prints a (misleading, in this case) error message. `error()` is also not good since we might have no fail pipe to send information back on. I think the best would be to have a function that prints a clear error message to stderr, then quits with a clear error code. Since the chance that stdout or stderr actually go somewhere is not that small: if file actions for posix_spawn did not work, the standard fork() fd inheritance applies, and the output goes to the parents output and can hopefully be spotted somewhere. If stdout/err are not open or not connected to anything we can read, we still have the exit code. I'll think up something. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29939#discussion_r2877092829
