On Thu, 17 Oct 2024 23:11:22 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> There is a race between JVMTI NotifyFramePop function and FramePop event >> posting code. >> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with >> depth 0 is requested by NotifyFramePop at the time when the target frame is >> in exit epilogue, and MethodExit/FramePop events are being posted for it. >> >> Testing: >> - verified locally with new test (developed by Chris): >> `serviceability/jvmti/events/NotifyFramePopStressTest` >> - TBD: mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > no need in raw monitor - removed test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 66: > 64: char* name = nullptr; > 65: > 66: pop_count++; I think there is still a concern that once this increment is done, the next iteration in control() can start. It will try to suspend this thread, which I think can happen in the 3 JVMTI calls below, and controll() will then call NotifyFramePop(), which will clobber last_notify_method. I think just moving this increment to the end will resolve that issue, or at least move it to after the last_notify_method reference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805577010
