JDK-8041934 : 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
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-04-25
  • Updated: 2018-01-19
  • Resolved: 2014-05-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b15Fixed
Related Reports
Cloners :  
JDK-8043571 - CLONE - 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
Relates :  
JDK-6471769 - Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth out of sync")
Relates :  
JDK-8043314 - Fix for JDK-8041934 causes assert(is_interpreted_frame()) failed: interpreted frame expected
Relates :  
JDK-8154989 - For JVMTI method exits from native wrapper frames, read in the native results from the correct location
Relates :  
JDK-8043162 - Remove com/sun/jdi/RepStep.java from ProblemList.txt
Description
com/sun/jdi/RepStep.java
 
    Assert failure on all platforms:
;; Using jvm: "/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-i586/jre/lib/i386/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/212850.amurillo/s/src/share/vm/prims/jvmtiThreadState.cpp:284), pid=31681, tid=4151782256
#  assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b10) (build 1.9.0-ea-fastdebug-b10)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-internal-201404242128.amurillo.8030011-update-hs--fastdebug compiled mode linux-x86 )
# Core dump written. Default location: /export/local/aurora/sandbox/results/workDir/com/sun/jdi/RepStep/core or core.31681
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0xf6116400):  JavaThread "main" [_thread_in_vm, id=31686, stack(0xf7722000,0xf7773000)]

Stack: [0xf7722000,0xf7773000],  sp=0xf7771760,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xdf86a5]  VMError::report_and_die()+0x185;;  VMError::report_and_die()+0x185
V  [libjvm.so+0x5f3cc8]  report_vm_error(char const*, int, char const*, char const*)+0x68;;  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0xa1b2f7]  JvmtiThreadState::cur_stack_depth()+0xc7;;  JvmtiThreadState::cur_stack_depth()+0xc7
V  [libjvm.so+0x9e737a]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x57a;;  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x57a
V  [libjvm.so+0x822411]  InterpreterRuntime::post_method_exit(JavaThread*)+0xe1;;  InterpreterRuntime::post_method_exit(JavaThread*)+0xe1
j  java.lang.Object.hashCode()I+0
j  java.util.HashMap.hash(Ljava/lang/Object;)I+9
j  java.util.HashMap.get(Ljava/lang/Object;)Ljava/lang/Object;+2
j  sun.reflect.Reflection.filterMethods(Ljava/lang/Class;[Ljava/lang/reflect/Method;)[Ljava/lang/reflect/Method;+13
j  java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method;+40
J 728 C1 java.lang.Class.getMethod0(Ljava/lang/String;[Ljava/lang/Class;Z)Ljava/lang/reflect/Method; (126 bytes) @ 0xe63a11d4 [0xe63a1160+0x74]
J 726 C1 java.lang.Class.getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method; (64 bytes) @ 0xe6399704 [0xe6399640+0xc4]
J 724 C1 sun.launcher.LauncherHelper.validateMainClass(Ljava/lang/Class;)V (111 bytes) @ 0xe639d168 [0xe639cf20+0x248]
J 248 C1 sun.launcher.LauncherHelper.checkAndLoadMain(ZILjava/lang/String;)Ljava/lang/Class; (220 bytes) @ 0xe62738b4 [0xe6272b00+0xdb4]
v  ~StubRoutines::call_stub
V  [libjvm.so+0x83953d]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x17bd;;  .L625+0x25c
V  [libjvm.so+0xbb3099]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x19;;  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x19
V  [libjvm.so+0x836337]  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x67;;  JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x67
V  [libjvm.so+0x8a81d5]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x445;;  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x445
V  [libjvm.so+0x8de8ed]  jni_CallStaticObjectMethod+0x15d;;  jni_CallStaticObjectMethod+0x15d
C  [libjli.so+0x7a13]  JavaMain+0x803;;  JavaMain+0x803
C  [libpthread.so.0+0x6a49]
C  [libc.so.6+0xe2aee]  clone+0x5e
 
    Host: spb23200, Oracle Linux 6.4 (2.6.39-400.21.1.el6uek.x86_64)
    Options: -server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M
Comments
This fix was rolled back since it did not work. See JDK-8043571 for the continued work.
30-05-2014
If we are 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. A solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This will need updates to SharedRuntime::generate_native_wrapper() for all platforms.
07-05-2014
Reproduces with -Xcomp (on the debugee side). diff --git a/test/com/sun/jdi/RepStep.java b/test/com/sun/jdi/RepStep.java --- a/test/com/sun/jdi/RepStep.java +++ b/test/com/sun/jdi/RepStep.java @@ -163,7 +163,7 @@ mainArg.setValue(TARGET); Connector.Argument optionsArg = (Connector.Argument)connectorArgs.get("options"); - optionsArg.setValue(VMConnection.getDebuggeeVMOptions()); + optionsArg.setValue(VMConnection.getDebuggeeVMOptions() + " -Xcomp"); vm = launcher.launch(connectorArgs); System.out.println("launched: " + TARGET);
06-05-2014