On Tue, 13 May 2025 10:26:51 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 346: >> >>> 344: if (ret != EINVAL) >>> 345: detail = tmpbuf; >>> 346: } >> >> Pre-existing, possibly as follow-up: >> >> I wonder whether we can do more. I don't like how we either only print out >> the errno string, or only print out the "Default" detail (I don't like the >> "default" prefix since it's really useful context information about this >> errno). >> >> For a problem on this side, we mostly pass in errno, then swallow the >> "defaultdetail". E.g. for posix_spawn failure, we'd print e.g. "12:Out of >> memory\nPossible reasons: ... " (or whatever localized string strerror >> returns). >> >> For errors that happen inside the jspawnhelper (see line 790ff where we pass >> 0 for the errno), we print out "0:Bad code from spawn helper\nPossible >> reasons: ... ", so we swallow the errno we got from the jspawnhelper. >> >> Could we print out instead the default, then the errno string, then the >> Possible reasons text? E.g. >> "posix_spawn failed (12:Out of memory)\nPossible reasons: ..." >> or >> "Bad code from spawn helper (12:Out of memory)\nPossible reasons: ..." >> >> There is an issue of errnum values from the far side possibly intersecting >> with valid errno. Could be solved simply by assigning negative values to >> ERR_MALLOC, ERR_PIPE and ERR_ARGS. I am not aware of any errno values being >> negative. The errno printing would need to recognise these three values in >> addition to errno values. We also could remove the +3 workaround in the test. >> >> The only argument I see against is some vague form of backward >> compatibility, in case people get confused about the new information, or >> that existing tools parse this output. > > Yeah, I dislike `defaultDetail` naming and the fact we swallow it. I see good > reason to print it unconditionally. I think we can do this with just a little > code massaging. See new commit. It prints the message like: > > > Recursively executing 'JspawnhelperProtocol simulateCrashInChild4' > posix_spawn:0 > java.io.IOException: Cannot run program "pwd": Failed to exec spawn helper: > pid: 1405770, exit code: 4, error: 0 (none) > Possible reasons: > - Spawn helper ran into JDK version mismatch > - Spawn helper ran into unexpected internal error > - Spawn helper was terminated by another process > Possible solutions: > - Restart JVM, especially after in-place JDK updates > - Check system logs for JDK-related errors > - Re-install JDK to fix permission/versioning problems > - Switch to legacy launch mechanism with > -Djdk.lang.Process.launchMechanism=VFORK > > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1044) > at java.base/java.lang.Runtime.exec(Runtime.java:605) > at java.base/java.lang.Runtime.exec(Runtime.java:470) > at JspawnhelperProtocol.parentCode(JspawnhelperProtocol.java:58) > at JspawnhelperProtocol.main(JspawnhelperProtocol.java:232) I like this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24149#discussion_r2086751118
