On Fri, 20 Feb 2026 18:55:38 GMT, Chris Plummer <[email protected]> wrote:
> In the CR there is a simple jdb test case that shows if you try a "next" > command (single step OVER) after getting a MethodExit event (enabled with the > jdb "trace" command), the "next" does not stop after the method returns like > it should. Instead it just effectively resumes the debuggee until it hits > some other event (Breakpoint or MethodExit). > > The problem is that if NotifyFramePop is called while handling a MethodExit > event, OPAQUE_FRAME is returned. The debug agent mistakenly assumes this > means the method was native, so step->fromNative is set true. This messed up > initEvents() for the JDWP_STEP_DEPTH(OVER) case, which only enables events if > step->fromNative is false. Initially I fixed this by doing a check to see if > the method really is native so step->fromNative isn't incorrectly set true > when the frame is not native. However, I eventually concluded that > JDWP_STEP_DEPTH(OVER) should enable stepping even if the method is native. In > fact it has to or else there will be no single step event when returning from > the native method. I then noticed the comments in initEvents() seemed to be > very bit rotten and did not describe what was actually going on in the code. > In the end the concern isn't with whether or not the method is native, but > whether or not NotifyFramePop failed, so I renamed fromNative to > notifyFramePopFailed and cleaned up the comments. > > In JdbMethodExitTest, I made a very slight modification that caused the the > failure reported in the CR. I replaced a "step up" call with "next". The > causes the JDWP_STEP_DEPTH(OUT) case to be triggered instead of > JDWP_STEP_DEPTH(OVER). > > Tested by running all tier1, tier2, tier3, and tier5 svc CI test tasks. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29849#pullrequestreview-3850247431
