JDK-8288949 : serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 19,20
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2022-06-22
  • Updated: 2022-08-04
  • Resolved: 2022-07-06
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 19 JDK 20
19 b30Fixed 20Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8288988 :  
test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java is failing after JDK-8278053 unexcluded the test.

# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (/src/hotspot/share/prims/jvmtiThreadState.cpp:628), pid=28685, tid=28973
#  assert(_cur_stack_depth == num_frames) failed: cur_stack_depth out of sync _cur_stack_depth: 16 num_frames: 15
# JRE version: Java(TM) SE Runtime Environment (19.0+28) (fastdebug build 19-ea+28-2105)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-ea+28-2105, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x13d7a44]  JvmtiThreadState::cur_stack_depth()+0xc4
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_serviceability/scratch/1/core.28685)
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

Current thread (0x00007f04c841b280):  JavaThread "MainThread" [_thread_in_vm, id=28973, stack(0x00007f049d2e9000,0x00007f049d3ea000)]

Stack: [0x00007f049d2e9000,0x00007f049d3ea000],  sp=0x00007f049d3e7f00,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x13d7a44]  JvmtiThreadState::cur_stack_depth()+0xc4
V  [libjvm.so+0x13923b9]  JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0xb9
V  [libjvm.so+0x139590e]  JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x1ae
V  [libjvm.so+0xff779b]  InterpreterRuntime::post_method_exit(JavaThread*)+0xbb
j  jdk.internal.vm.Continuation.enter0()V+9 java.base@19-ea
j  jdk.internal.vm.Continuation.enter(Ljdk/internal/vm/Continuation;Z)V+1 java.base@19-ea
J 6146  jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base@19-ea (0 bytes) @ 0x00007f04b891e04b [0x00007f04b891dfc0+0x000000000000008b]
j  jdk.internal.vm.Continuation.run()V+152 java.base@19-ea
j  ContStackDepthTest.getNextFib()Ljava/math/BigInteger;+3
j  ContStackDepthTest.fibTest()V+79
J 5818 c1 ContStackDepthTest.main([Ljava/lang/String;)V (79 bytes) @ 0x00007f04b0d42d14 [0x00007f04b0d42a00+0x0000000000000314]
J 5824 c1 java.lang.invoke.LambdaForm$DMH+0x0000000801003400.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V java.base@19-ea (14 bytes) @ 0x00007f04b0d40ed4 [0x00007f04b0d40ac0+0x0000000000000414]
J 5947 c1 java.lang.invoke.LambdaForm$MH+0x0000000801004800.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@19-ea (38 bytes) @ 0x00007f04b0c13f74 [0x00007f04b0c13980+0x00000000000005f4]
J 5948 c1 java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@19-ea (24 bytes) @ 0x00007f04b0c130ac [0x00007f04b0c12940+0x000000000000076c]
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@19-ea
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@19-ea
J 3300 c2 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@19-ea (108 bytes) @ 0x00007f04b8967538 [0x00007f04b8967280+0x00000000000002b8]
J 5702 c1 com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V (476 bytes) @ 0x00007f04b0b5c80c [0x00007f04b0b5b3e0+0x000000000000142c]
J 5698 c1 java.lang.Thread.run()V java.base@19-ea (19 bytes) @ 0x00007f04b0bd2d3c [0x00007f04b0bd2ba0+0x000000000000019c]
v  ~StubRoutines::call_stub 0x00007f04b800dd47
V  [libjvm.so+0x1013fa5]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505
V  [libjvm.so+0x1014834]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4
V  [libjvm.so+0x1014ca7]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77
V  [libjvm.so+0x1197fbb]  thread_entry(JavaThread*, JavaThread*)+0x12b
V  [libjvm.so+0x1aa093c]  JavaThread::thread_main_inner()+0x23c
V  [libjvm.so+0x1aabfa0]  Thread::call_run()+0x100
V  [libjvm.so+0x175db14]  thread_native_entry(Thread*)+0x104
Changeset: 9a0fa824 Author: Ron Pressler <rpressler@openjdk.org> Date: 2022-07-06 20:53:13 +0000 URL: https://git.openjdk.org/jdk19/commit/9a0fa8242461afe9ee4bcf80523af13500c9c1f2

A pull request was submitted for review. URL: https://git.openjdk.org/jdk19/pull/66 Date: 2022-06-24 09:23:26 +0000

The failure reproduces even after reverting the fixes for JDK-8278053 and JDK-8286103, and even without the +DeoptimizeALot flag. But yes, it occurs now because the test was removed from the exclude lists.

I don't consider: JDK-8278053 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp to be unrelated to these test failures. JDK-8278053 was used to remove serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java from the ProblemList-Xcomp.txt file and the test now fails in exactly that configuration. I've looked at https://git.openjdk.org/jdk19/pull/12 and it is not at all clear what testing was done prior to integration of that fix. Since that fix removed the test from the ProblemList-Xcomp.txt file, a Tier4 test run should have been done to verify that the test no longer fails in Tier4. Since the test still fails, it should not have been removed from the ProblemList-Xcomp.txt file. I could see updating the entry to refer to a new bug, but not removal. We already have 14 failures of the test between the JDK19 and JDK20 CIs.

This bug is unrelated to the linked issues. They might have hidden it by crashing in a different way. This failure occurs before the first freeze/thaw.

The enterSpecial special nmethod is always compiled and run even in interp_only_mode. It calls get_resolve_static_call_stub to resolve its target (Continuation::enter), which returns the compiled entry, even in interp_only_mode.