On Thu, 17 Oct 2024 00:55:58 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp >> line 84: >> >>> 82: deallocate(jvmti, jni, name); >>> 83: deallocate(jvmti, jni, (void*)last_notify_method); >>> 84: fatal(jni, "FramePop event in wrong method\n"); >> >> This is the main purpose for this test. It used to just set `failed` and >> then continue to run to detect additional errors, and then java side of the >> test calls `failed()` to detect the failure. Now you exit the test process >> when there is a failure. There is actually no purpose served for the >> `failed` flag anymore. > >> Have you verified that the test still detects the bug? In other words, if >> you disabled the fix, does the test fail? I was just a bit worried that with >> all the changes to it, it might not be still be properly detecting the bug, >> and I looked in the mach5 history and don't see this test failing for a >> couple of weeks now. > > The test is failing locally with event in a wrong method as expected. > But the latest changes broke the test. Now it is failing at > `deallocate(jvmti, jni, csig)`. > I suspect it is related to the latest changes for `last_notify_method` but > have not proved it yet. > This is the main purpose for this test. It used to just set failed and then > continue to run to detect additional errors, and then java side of the test > calls failed() to detect the failure. Now you exit the test process when > there is a failure. There is actually no purpose served for the failed flag > anymore. Okay, I'll try to remove `fatal()` and retest it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803971275
