Note that RepStep was just added to ProblemList due to this issue and will have to be removed from there when the fix is integrated.
Mikael On 2014-05-08 08:06, Staffan Larsen wrote: > All, > > This is a fix for an assert in JVMTI that verifies that JVMTI’s internal > notion of the number of frames on the stack is correct. > > When running in -Xcomp mode and enable single-stepping (or method_entry/exit) > we will revert all frames on the stack to be run by the interpreter. Only the > interpreter can send single-step and method_entry/exit. However, if one of > the frames is a native wrapper, that frame will not be reverted (presumably > because we don't know how to do that). This will cause us to miss a > method_exit event when that native frame is popped. This in turn will mess up > the logic in JVMTI that keeps track of the number of frames currently on the > stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. > > The proposed solution is to include a method_exit event in the native wrapper > frame if interpreted mode has been enabled. This needs updates to > SharedRuntime::generate_native_wrapper() for all platforms. > > Kudos to Rickard for helping me write the code. > > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8041934 > > The fix has been verified by running the failing test in JPRT with -Xcomp. > > Thanks, > /Staffan >
