On Mon, 7 Sep 2026 13:14:41 GMT, Jorn Vernee <[email protected]> wrote:
>> See the JBS issue for the extended problem description. >> >> Native threads that were attached to the JVM through an FFM upcall are >> automatically detached from the VM when they join/terminate. However, if a >> native thread tries to terminate after the VM has exited without going >> through `DestroyJavaVm` (e.g. as a result of calling `System.exit`), they >> will block in `VM_Exit::block_if_vm_exited` inside `DetachCurrentThread`. >> This may happen for instance when they try to join after the JVM has exited >> in an `atexit` handler. >> >> This patch adds a check before trying to detach the thread to see if the VM >> has exited and bails out if it has. This does not prevent issues as a result >> of a race between the VM exiting and the thread joining, but it does prevent >> issues in the more comment case where a thread simply outlives the VM. >> >> --------- >> - [X] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > Indentation > > Co-authored-by: David Holmes <[email protected]> test/jdk/java/foreign/detachafterexit/TestDetachAfterExit.java line 88: > 86: > 87: System.out.println("[main] Waiting for callback..."); > 88: while (!flag.get()) { `cb` sets `flag` in the callback, but the native worker may still be executing I think. Can the `main` thread then close the arena (freeing the upcall stub) and invoke `exit(0)` before the worker returns to native code? If so, we could be exposed to use-after-free and/or leave the worker in an unknown state. Is there a more robust way of handshaking or can we use a timed delay here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32686#discussion_r3956623643
