RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v2]

David Holmes dholmes at openjdk.org
Thu Jul 10 08:18:42 UTC 2025


On Thu, 10 Jul 2025 08:12:54 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception.
>> 
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

That fixes the observed problem, but I find the existing test logic somewhat awkward. You only need a finally block to ensure something happens if an exception occurred - but here if you get an exception why do we care about joining the vthread? We don't know what the exception was or what it implies about the state of the vthread.

Also using wait/notify without a loop on the wait and checking a state variable is not the correct usage pattern and would be affected by spurious wakeups.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3004487073


More information about the serviceability-dev mailing list