On Tue, 25 Mar 2025 19:35:36 GMT, Dan Lutker <dlut...@openjdk.org> wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to >> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report >> the errors into stdout, but not to the relevant `IOException`. So, if the >> application is configured to only capture the exception logs (e.g. through >> `java.util.logging`), we will miss any output from `jspawnhelper`, and user >> would be left without a clue what have happened. We have seen customers >> spending weeks trying to figure out what went wrong. >> >> It would be good to provide useful `IOException` when `jspawnhelper` fails. >> We already have a precedent with vmError [printing helpful >> suggestions](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/vmError.cpp#L422) >> when VM fails, we can do a similar thing here. >> >> I am very open to bike-shedding about the actual message :) >> >> Additional testing: >> - [x] Ad-hoc experiments with breaking jspawnhelper >> - [x] macos-aarch64-server-fastdebug, `java/lang/Process >> java/lang/ProcessBuilder` > > src/java.base/unix/native/libjava/ProcessImpl_md.c line 324: > >> 322: #define SPAWN_HELPER_INTERNAL_ERROR_MSG "\n" \ >> 323: "Possible reasons:\n" \ >> 324: " - Spawn helper ran into JDK version or configuration problems\n" \ > > Can we be clear and say "Spawn helper ran into a mismatch between the running > JDK and the version on disk" or something similar? We don't know the exact reason for jspawnhelper failure, so that would be a bad message that might push users to wrong resolution path. Instead, like `vmError`, we list most frequent possibilities and let users follow-up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2012817709
