Bug ID: JDK-8043571 [REDO] JDK-8041934 com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack

JDK-8043571 : [REDO] 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: 8u20,9,10,11,22

Priority: P3
Status: Open
Resolution: Unresolved

Submitted: 2014-05-20
Updated: 2024-09-03

Versions (Unresolved/Resolved/Fixed)

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.

Other
tbdUnresolved

Related Reports

Blocks :	JDK-8187289 - NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled
Cloners :	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
Duplicate :	JDK-8060121 - nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001 assert _cur_stack_depth == count_frames()
Duplicate :	JDK-8205423 - assert(_cur_stack_depth == count_frames()) while debugging core reflection with IntelliJ
Duplicate :	JDK-8152854 - VM crashed with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
Duplicate :	JDK-8287149 - vmTestbase/vm/mlvm/indy/stress/jdi/breakpointInCompiledCode/Test.java crashes on macosx_aarch64
Duplicate :	JDK-8193081 - assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
Relates :	JDK-8043314 - Fix for JDK-8041934 causes assert(is_interpreted_frame()) failed: interpreted frame expected
Relates :	JDK-8323214 - JDI StepRequest/addClassFilter_rt/filter_rt003 fails fatal error: memory leak: allocating without ResourceMark
Relates :	JDK-8306679 - com/sun/jdi/InterruptHangTest.java asserts with -Xcomp -Dmain.wrapper=Virtual options
Relates :	JDK-6471769 - Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth out of sync")
Relates :	JDK-8043162 - Remove com/sun/jdi/RepStep.java from ProblemList.txt
Relates :	JDK-8154989 - For JVMTI method exits from native wrapper frames, read in the native results from the correct location

Sub Tasks

JDK-8218702 :	[TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors - Resolved
JDK-8320130 :	Problemlist 2 vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt tests with Xcomp - Resolved

Description

[This is a clone of the original report since the fix pushed in that bug was backed out]


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

JDK-8306679 is likely a dup and impacts com/sun/jdi/InterruptHangTest.java on I believe every -Xcomp run when virtual threads are used. Update: [~sspitsyn] says it is not a dup of JDK-8306679 since JDK-8306679 is due to virtual threads.
03-09-2024
comment from wrong bug
30-08-2024
test/jdk/com/sun/jdi/RepStep.java problem-listed on all platforms; need to problem list 2 tests from hotspot/jtreg in Xcomp mode: vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001/TestDescription.java vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt003/TestDescription.java
15-11-2023
[~amenkov] If you don't plan on fixing this soon, you should probably problem list it for -Xcomp. Although I think it can happen without -Xcomp, it is very rare, so probably just doing -Xcomp problem listing would be best.
13-11-2023
Here's the crashing thread's stack trace for the jdk-22+21-1592-tier7 sighting: vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt/filter_rt001/TestDescription.java --------------- T H R E A D --------------- Current thread (0x000001b1013b2250): JavaThread "thread1" [_thread_in_vm, id=57252, stack(0x000000429f200000,0x000000429f300000) (1024K)] Stack: [0x000000429f200000,0x000000429f300000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xc8cc91] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:236) V [jvm.dll+0xf2d4bf] VMError::report+0x147f (vmError.cpp:1000) V [jvm.dll+0xf2f9b5] VMError::report_and_die+0x645 (vmError.cpp:1819) V [jvm.dll+0xf300d4] VMError::report_and_die+0x64 (vmError.cpp:1584) V [jvm.dll+0x55d5cb] report_vm_error+0x5b (debug.cpp:191) V [jvm.dll+0xa86ac2] JvmtiThreadState::cur_stack_depth+0xd2 (jvmtiThreadState.cpp:832) V [jvm.dll+0xa5a51a] JvmtiExport::post_method_exit_inner+0x3ca (jvmtiExport.cpp:1931) V [jvm.dll+0xa59da9] JvmtiExport::post_method_exit+0x349 (jvmtiExport.cpp:1882) V [jvm.dll+0x7ce449] InterpreterRuntime::post_method_exit+0xb9 (interpreterRuntime.cpp:1256) C 0x000001b0b37d50e5 (no source info available) The last pc belongs to native method entry point (kind = native) (printed below). Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.System.nanoTime()J+0 java.base@22-ea j java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(JLjava/util/concurrent/TimeUnit;)Z+57 java.base@22-ea j nsk.share.jdi.ThreadState.waitForState(Ljava/lang/String;)V+38 j nsk.share.jdi.ThreadState.setAndWait(Ljava/lang/String;Ljava/lang/String;)V+7 j nsk.jdi.StepRequest.addClassFilter_rt.Thread1filter_rt001a.run()V+20 J 2574 c2 java.lang.Thread.run()V java.base@22-ea (23 bytes) @ 0x000001b0b40e259c [0x000001b0b40e24e0+0x00000000000000bc] v ~StubRoutines::call_stub 0x000001b0b37c107d Lock stack of current Java thread (top to bottom): <empty>
21-10-2023
Changed incorrect sub-component to hotspot/jvmti.
20-06-2018
The changes here are being 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: 1. Decrement the current stack depth (to keep JVMTI’s bookkeeping wrt the number of stack frames correct) 2. 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. Since, at this point, we are not reading in the native return value, I have created the issue JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. With these changes, at this point, there is some clobbering of the sparc registers happening -- this is being addressed currently.
22-02-2017
ILW = (M (seen only during debugging), M (intermittent normally, consistent only with -Xcomp), L (workaround exists -- it is to use -Xint)) = P4
22-02-2017
com/sun/jdi/RepStep.java has been added to ProblemList.txt. Remember to remove it.
30-05-2014
RULE com/sun/jdi/RepStep.java Crash Internal Error ...jvmtiThreadState.cpp...assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
20-05-2014