JDK-8315980 : serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 21,22,24
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-09-11
  • Updated: 2025-05-21
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 26
26Unresolved
Related Reports
Relates :  
JDK-8345427 - Crash in serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java
Sub Tasks
JDK-8317449 :  
ProblemList serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java on several platforms - Resolved
JDK-8334592 :  
ProblemList serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java in jdk21 on all platforms - Resolved
Description
This test failed once for me with -Xcomp -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+DeoptimizeALot. The output is

Agent_OnLoad started
Agent_OnLoad finished
Synchronization point checkStatus(0) called.
Data 0x7f56d4020840 0x7f56d4035150
Agent: wait for thread to start
Agent: started
Agent: Stacktrace of virtual thread is incorrect: doesn't start from enter(...):
JVMTI Stack Trace: frame count: 8
 0: java/lang/VirtualThread: runContinuation()V
 1: java/lang/VirtualThread$$Lambda.0x00007f56630502e0: run()V
 2: java/util/concurrent/ForkJoinTask$RunnableExecuteAction: exec()Z
 3: java/util/concurrent/ForkJoinTask: doExec()I
 4: java/util/concurrent/ForkJoinPool$WorkQueue: topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V
 5: java/util/concurrent/ForkJoinPool: scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;II)I
 6: java/util/concurrent/ForkJoinPool: runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V
 7: java/util/concurrent/ForkJoinWorkerThread: run()V

FATAL ERROR in native method: incorrect stacktrace
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xf87652]  jni_FatalError+0x92  (jni.cpp:631)
C  [libGetStackTraceNotSuspendedStress.so+0x2899]  test_stack_trace(_jvmtiEnv*, JNIEnv_*, _jobject*)+0x139  (jni.h:844)
C  [libGetStackTraceNotSuspendedStress.so+0x3595]  agentProc(_jvmtiEnv*, JNIEnv_*, void*)+0x105  (libGetStackTraceNotSuspendedStress.cpp:104)
C  [libGetStackTraceNotSuspendedStress.so+0x2252]  agent_thread_wrapper+0x32  (jvmti_thread.h:179)
V  [libjvm.so+0x11a1df9]  JvmtiAgentThread::call_start_function()+0x59  (jvmtiImpl.cpp:89)
V  [libjvm.so+0xeb7d9c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
V  [libjvm.so+0x17a398a]  Thread::call_run()+0xba  (thread.cpp:220)
V  [libjvm.so+0x14a471a]  thread_native_entry(Thread*)+0x12a  (os_linux.cpp:786)

If I read the test output correctly, it has printed the stack trace of the carrier thread (not the virtual thread). It is possible that calling GetStackTrace during a transition will return the stack trace of the carrier?
Comments
Here's a log file snippet for he jdk-24+14-1511-tier1 sighting: serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java #section:main ----------messages:(6/368)---------- command: main -agentlib:GetStackTraceNotSuspendedStress GetStackTraceNotSuspendedStressTest reason: User specified action: run main/othervm/native -agentlib:GetStackTraceNotSuspendedStress GetStackTraceNotSuspendedStressTest started: Wed Sep 04 18:16:02 GMT 2024 Mode: othervm [/othervm specified] finished: Wed Sep 04 18:16:10 GMT 2024 elapsed time (seconds): 8.025 ----------configuration:(0/0)---------- ----------System.out:(21/1145)---------- Agent_OnLoad started Agent_OnLoad finished Synchronization point checkStatus(0) called. Data 0x7f7e42704090 0x600002bc0150 Agent: wait for thread to start Agent: started Agent: Stacktrace in virtual thread is incorrect: count: 0 Thread: 0x7f7e32708768, name: VThread-Producer-59, state(5): ALIVE RUNNABLE, attrs: virtual daemon JVMTI Stack Trace: frame count: 0 FATAL ERROR in native method: Incorrect frame count Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xa4aeba] jni_FatalError+0xca C [libGetStackTraceNotSuspendedStress.dylib+0x5f56] agentProc(_jvmtiEnv*, JNIEnv_*, void*)+0x3d6 C [libGetStackTraceNotSuspendedStress.dylib+0x61a1] agent_thread_wrapper(_jvmtiEnv*, JNIEnv_*, void*)+0x31 V [libjvm.dylib+0xc7fa4c] JvmtiAgentThread::start_function_wrapper(JavaThread*, JavaThread*)+0x6c V [libjvm.dylib+0x9af935] JavaThread::thread_main_inner()+0x1a5 V [libjvm.dylib+0x11b16bc] Thread::call_run()+0xbc V [libjvm.dylib+0xf14202] thread_native_entry(Thread*)+0x122 C [libsystem_pthread.dylib+0x6202] _pthread_start+0x63 C [libsystem_pthread.dylib+0x1bab] thread_start+0xf ----------System.err:(5/782)---------- WARNING: A restricted method in java.lang.System has been called WARNING: java.lang.System::loadLibrary has been called by GetStackTraceNotSuspendedStressTest in an unnamed module (file:/System/Volumes/Data/mesos/work_dir/slaves/6bbe0543-8c5a-457e-b0ca-dfa2833be967-S2709/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/cb3f128f-f51e-42cb-a355-c22de6e5ff6f/runs/f1326e50-b32a-4823-b4b5-107ad0b16a41/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.d/) WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module WARNING: Restricted methods will be blocked in a future release unless native access is enabled ----------rerun:(34/8022)*---------- <snip> result: Failed. Unexpected exit from test [exit code: 134]
04-09-2024
Another "zero frame count for virtual thread" failure
01-06-2024
Latest failure modes all seem to have the zero frame count.
08-03-2024
[~sspitsyn] Just looking at Dan's latest sighting and it looks like it might be a different failure mode than the original one that I saw. In Dan's sighting, there are 0 frames, which hints that the virtual thread has been started hasn't been scheduled yet.
10-01-2024
Here's a log file snippet from the jdk-22+31-2302-tier3 sighting: serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java #section:main ----------messages:(6/368)---------- command: main -agentlib:GetStackTraceNotSuspendedStress GetStackTraceNotSuspendedStressTest reason: User specified action: run main/othervm/native -agentlib:GetStackTraceNotSuspendedStress GetStackTraceNotSuspendedStressTest started: Tue Jan 09 20:12:55 GMT 2024 Mode: othervm [/othervm specified] finished: Tue Jan 09 20:13:04 GMT 2024 elapsed time (seconds): 9.229 ----------configuration:(0/0)---------- ----------System.out:(21/1145)---------- Agent_OnLoad started Agent_OnLoad finished Synchronization point checkStatus(0) called. Data 0x7f91b4306010 0x600003908150 Agent: wait for thread to start Agent: started Agent: Stacktrace in virtual thread is incorrect: count: 0 Thread: 0x7f91b420ad20, name: VThread-Consumer-25, state(5): ALIVE RUNNABLE, attrs: virtual daemon JVMTI Stack Trace: frame count: 0 FATAL ERROR in native method: Incorrect frame count Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xa4924a] jni_FatalError+0xca C [libGetStackTraceNotSuspendedStress.dylib+0x5f56] agentProc(_jvmtiEnv*, JNIEnv_*, void*)+0x3d6 C [libGetStackTraceNotSuspendedStress.dylib+0x61a1] agent_thread_wrapper(_jvmtiEnv*, JNIEnv_*, void*)+0x31 V [libjvm.dylib+0xc7c92c] JvmtiAgentThread::start_function_wrapper(JavaThread*, JavaThread*)+0x6c V [libjvm.dylib+0x9aea15] JavaThread::thread_main_inner()+0x1a5 V [libjvm.dylib+0x117be8c] Thread::call_run()+0xbc V [libjvm.dylib+0xefa6d2] thread_native_entry(Thread*)+0x122 C [libsystem_pthread.dylib+0x6202] _pthread_start+0x63 C [libsystem_pthread.dylib+0x1bab] thread_start+0xf ----------System.err:(3/174)---------- java version "22-ea" 2024-03-19 Java(TM) SE Runtime Environment (fastdebug build 22-ea+31-2302) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 22-ea+31-2302, mixed mode) ----------rerun:(36/8111)*---------- <snip> result: Failed. Unexpected exit from test [exit code: 134]
09-01-2024
There are currently 7 sightings of serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java failing in the JDK22 CI. There are sightings of this test failing in test tasks that are not specific to virtual threads so ProblemListing this test has to go a bit wider. So far failures have been spotted on linux-aarch64, linux-x64, and windows-x64.
03-10-2023
Okay, thanks. Will need to reproduce it to understand the root cause.
13-09-2023
=== JDK 21 == start: notifyJvmtiMount(/*hide*/true); cont.run() mount(); notifyJvmtiStart(); park: notifyJvmtiUnmount(/*hide*/true); unmount(); Continuation.yield notifyJvmtiUnmount(/*hide*/false); continue: notifyJvmtiMount(/*hide*/true); cont.run(); mount(); notifyJvmtiMount(/*hide*/false); === JDK 22 == start: notifyJvmtiMount(/*hide*/true); mount(); cont.run(); notifyJvmtiStart(); park: notifyJvmtiUnmount(/*hide*/true); Continuation.yield unmount(); notifyJvmtiUnmount(/*hide*/false); continue: notifyJvmtiMount(/*hide*/true); mount(); cont.run(); notifyJvmtiMount(/*hide*/false); The callouts to JVMTI are unchanged, it's just the code between hide=true and hide=false that has changed.
13-09-2023
This needs to be investigated sooner rather than later, at least in 22. My concern is it can be an impact from the Alan's fix for: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing There is a minor phase mismatch in mount state transition view between VirtualThread class and JVMTI. This can cause a small part of transition incorrectly observed by JVMTI. For instance, with the fix of 8315373 we have: // notify JVMTI before mount notifyJvmtiMount(/*hide*/true); + mount(); Before the fix the notifyJvmtiMount() and mount() were called the opposite order: // re-mount mount(); notifyJvmtiMount(/*hide*/false); Need to check if this could be a root cause of this issue.
13-09-2023