RFR: 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected [v4]

David Holmes dholmes at openjdk.org
Fri Feb 21 03:19:53 UTC 2025


On Fri, 21 Feb 2025 01:31:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`.  It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: move suspend point from post_single_step() to get_jvmti_thread_state()

src/hotspot/share/prims/jvmtiExport.cpp line 428:

> 426:       // suspend here if there is a suspend request
> 427:       ThreadBlockInVM tbivm(thread, true /* allow suspend */);
> 428:     }

This positioning seems better than the previous one, but it still causes me concern as a get function should not really have a side-effect of blocking due to suspension, in my view. What does the actual call-stack look like when we get here? We are obviously missing a suspension check for the current thread, but I still feel that should be higher-up the call-stack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1964731467


More information about the hotspot-runtime-dev mailing list