RFR: 8307990: jspawnhelper must close its writing side of a pipe before reading from it
Volker Simonis
simonis at openjdk.org
Mon May 22 10:47:52 UTC 2023
On Wed, 17 May 2023 20:03:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:
> > > Should this issue have a CSR for any behavioral changes?
> >
> >
> > Well, you can certainly argue that every bug fix is a behavioral changes, right :)
> > But seriously, I don't see how this PR could require a CSR. The only behavioral change is really that `jspawnhelper` can now no longer block and deadlock. But that's exactly how it should have behaved in the first place.
>
> Yes, some judgement is needed on behavioral changes; this was broached in portions of my recent talk to the JCP EC:
>
> "Contributing to OpenJDK: Participating in stewardship for the long-term" https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-04-12/Contributing_to_OpenJDK_2023_04_12.pdf
>
> The process spawning code is apparently tricky and subtle, so much so that this will be apparently the third attempt at it since JDK 12. (I still have memories of various platform-specific issues in process handling from my time maintaining the launcher.)
>
> So I don't think the applicability of a CSR for this change should be dismissed
I've created a [Release Note](https://bugs.openjdk.org/browse/JDK-8308297) (please feel to review it :) which outlines the "*behavioral change*". But this change is really just a simple bug fix for the case where the JVM leaves a hanging process (`jspawnhelper`) behind when it crashes. I don't really see see how a CSR will fit in here unless we start to treat crashes as "defined behavior" and start tracking them across releases.
If you still think a CSR will be needed, please advice how it should look like?
> and personally I would prefer a change like this be made early in JDK 22 rather than a few weeks before JDK 21 rampdown; it is easier to address any bug tail early in 22 rather than late in 21.
First, this is a bug fix for an issue which impacts production usage of the JDK. Second, tt's a "first-day" bug introduced by [JDK-5049299](https://bugs.openjdk.org/browse/JDK-5049299) for JDK 8 (initially only active on Solaris). It started to manifest on Linux in JDK 13 when the `POSIX_SPAWN` launching mechanism was ported to Linux as well, **but** it was only detected some time after JDK 17 was released when a higher rate of production services started to migrate to JDK 17.
I really don't want to go into a bike-shedding discussion about "*LTS releases are not special*", but I think this is a serious enough bug with a simple enough fix to resolve it as quick as possible (and downport it to JDK 17 as fast as possible). We are still more than two weeks before RDP 1 and we still have more than three month before GA so I don't see a reason not to fix this now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1556989917
More information about the core-libs-dev
mailing list