<div dir="ltr"><div>Unfortunately, after diving into this, I found that the jspawnhelper version checks (JDK-8325621) that guard against JDK in-place-updates also rely on the liveness signal. See comment in <a href="https://bugs.openjdk.org/browse/JDK-8362257">https://bugs.openjdk.org/browse/JDK-8362257</a>. <br></div><div><br></div><div>I find the check itself quite questionable, but I did not want to break that one too, so I decided to not remove the liveness check. <br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jul 16, 2025 at 7:26 AM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com">thomas.stuefe@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks, Roger, I will proceed with removing the old workaround then.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 15, 2025 at 5:05 PM Roger Riggs <<a href="mailto:roger.riggs@oracle.com" target="_blank">roger.riggs@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Thomas,<br>
<br>
Simpler is better on both sides of the protocol.<br>
The version check will have happened before this part of the protocol so <br>
there's no confusion about matching expectations.<br>
I agree that removing it is preferred.<br>
<br>
Roger<br>
<br>
<br>
On 7/15/25 10:44 AM, Thomas Stüfe wrote:<br>
> Hi,<br>
><br>
> I am currently working on removing (eventually) the vfork mode. Before <br>
> we can do this, we need a bit better error diagnostics. I do this by <br>
> gently improving the error handling throughout the code, so that we <br>
> can generate IOExceptions based on more exact knowledge.<br>
><br>
> While working at this, I re-examined the "send aliveness ping from <br>
> jspawnhelper to parent" logic again I introduced back in 2019 as a <br>
> workaround for an obscure glibc bug with posix_spawn (see <br>
> <a href="https://bugs.openjdk.org/browse/JDK-8223777" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8223777</a>). I found that it was not <br>
> needed anymore since the glibc was fixed, so I started removing that <br>
> workaround (<a href="https://bugs.openjdk.org/browse/JDK-8362257" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8362257</a>).<br>
><br>
> But then it occurred to me that an obscure part of the jspawnhelper <br>
> diagnostics introduced with <br>
> <a href="https://bugs.openjdk.org/browse/JDK-8226242" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8226242</a> piggy-backs on the <br>
> aliveness ping for its <br>
> "detect-abnormal-process-termination-before-exec" capabilities. Works <br>
> like this:<br>
><br>
> A jspawnhelper starts<br>
> B jspawnhelper enters childProcess() and sends alivenes ping<br>
> C jspawnhelper does a bunch of other things<br>
> D jspawnhelper exec's<br>
><br>
> In the parent, we count abnormal child terminations that occur before <br>
> the aliveness ping (B) as "spawn error" and print the signal number.  <br>
> Without the aliveness ping we could not tell apart "jspawnhelper ends <br>
> abnormally due to a signal" from "jspawnhelper exec()'s the user <br>
> program successfully, user program runs and ends abnormally due to <br>
> signal".<br>
><br>
> However, the question is how important or even useful this part really is:<br>
> - for externally sent abnormal termination signals (SIGTERM etc), from <br>
> the caller's point of view it probably does not matter when it comes : <br>
> before or after exec().<br>
> - it only matters for synchronous termination signals (crashes) we <br>
> ourselves cause; but here it only covers crashes in a rather small <br>
> piece of code, before the liveness ping (B). Basically, just the first <br>
> part of jspawnhelper main(). Any crashes after the liveness ping are <br>
> still unrecognised by ProcessBuilder.start, and are instead handled by <br>
> the caller calling Process.waitFor().<br>
><br>
> There are two ways to deal with this:<br>
><br>
> We could do without the crash protection in point (A), which would <br>
> allow us to remove the liveness ping. I would very much prefer that. <br>
> It would simplify the jspawnhelper protocol and make it more robust. <br>
> Because we now don't have any communication in case no error happens - <br>
> there would be only a single bit of information sent back via fail <br>
> pipe, and only in case of an error. Fail pipe would stay quiet in case <br>
> of successful exec(). Abnormal child process termination in the first <br>
> part of jspawnhelper would be covered by the same path that detects <br>
> abnormal child process termination in user programs - Process.waitFor().<br>
><br>
> If we determine we really need this crash detection, we could at least <br>
> improve it: move the liveness ping to just-before the exec() call, so <br>
> that we cover all the area from A-D. Also, do it for all modes (FORK, <br>
> too), to simplify coding.<br>
><br>
> Bottomline: remove an obscure and complex small mechanism that only <br>
> helps a bit with detecting program errors (sigsegv etc) inside the <br>
> first part of jspawnhelper main() ?<br>
><br>
> Thanks, Thomas<br>
><br>
><br>
<br>
</blockquote></div>
</blockquote></div>