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

[Serguei Spitsyn]

On Thu, 13 Feb 2025 22:57:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> We can always create a test where a suspended target posts an event though, because the target can be seen as handshake-safe after switching to native in JvmtiJavaThreadEventTransition. So this fix would prevent posting events enabled after suspension (like this test is doing) but not before.

Right. It is important to prevent posting events enabled after suspension.

> This latter case would not be easy to fix since a callback is executed in native and we allow suspending in such state.

My understanding is that the event posting is intentionally racy. We can treat it as a thread suspension request has been processed in the middle of an event callback execution. We do not need to fix this as it is a part of the design.

> Now, I thought suspend only implied the target cannot execute new Java bytecodes (can’t find the precise definition in the JVMTI specs). 

Yes, the target should not execute new Java bytecodes after suspension.

> If that’s the case, why is this a bug in the VM and not a test issue? Or is this a case of still following the specs but trying to do the saner thing?

I treat it as VM/JVMTI bug as it looks silly when events are posted event though they were enabled after suspension. Yes, it is an attempt to do he saner thing.

Thank you for good questions!

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

PR Comment: https://git.openjdk.org/jdk/pull/23490#issuecomment-2660306484