Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"; JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT : hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George
