JDK-8366438 : Crash when running java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java#id0 on macos-aarch64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 26
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: other
  • CPU: aarch64
  • Submitted: 2025-08-29
  • Updated: 2025-09-12
  • Resolved: 2025-09-12
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
26Resolved
Related Reports
Duplicate :  
Relates :  
Description
I saw this crash in GHA testing for one of my PR - https://github.com/openjdk/jdk/pull/26764#issuecomment-3233848145

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000103bf9bbc, pid=12937, tid=29447
#
# JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-ashu-mehra-eb641188b3a0c241d95292a834404958c3e4e5dd)
# Java VM: OpenJDK 64-Bit Server VM (26-internal-ashu-mehra-eb641188b3a0c241d95292a834404958c3e4e5dd, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x2f5bbc]  void StackChunkFrameStream<(ChunkFrames)1>::next<RegisterMap>(RegisterMap*, bool)+0xbc
#

Back trace from error log:

Stack: [0x0000000170f80000,0x0000000171183000],  sp=0x0000000171181890,  free space=2054k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x2f5bbc]  void StackChunkFrameStream<(ChunkFrames)1>::next<RegisterMap>(RegisterMap*, bool)+0xbc
V  [libjvm.dylib+0xa4bca0]  stackChunkOopDesc::sender(frame const&, RegisterMap*)+0x15c
V  [libjvm.dylib+0xb85524]  vframeStream::vframeStream(oopDesc*, Handle)+0xc8
V  [libjvm.dylib+0xb2009c]  GetThreadSnapshotHandshakeClosure::do_thread(Thread*)+0x588
V  [libjvm.dylib+0xb1f67c]  ThreadSnapshotFactory::get_thread_snapshot(_jobject*, JavaThread*)+0x29c
V  [libjvm.dylib+0x5dc720]  JVM_CreateThreadSnapshot+0xa0
j  jdk.internal.vm.ThreadSnapshot.create(Ljava/lang/Thread;)Ljdk/internal/vm/ThreadSnapshot;+0 java.base@26-internal
j  jdk.internal.vm.ThreadSnapshot.of(Ljava/lang/Thread;)Ljdk/internal/vm/ThreadSnapshot;+1 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThread(Ljava/lang/Thread;Ljdk/internal/vm/ThreadDumper$JsonWriter;)Z+5 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreads(Ljdk/internal/vm/ThreadContainer;Ljdk/internal/vm/ThreadDumper$JsonWriter;)V+95 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToJson(Ljdk/internal/vm/ThreadDumper$TextWriter;)V+64 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToFile(Ljava/lang/String;ZZ)[B+62 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToJson(Ljava/lang/String;Z)[B+24 java.base@26-internal
v  ~StubRoutines::Stub Generator call_stub_stub 0x0000000114b44454
V  [libjvm.dylib+0x4fc1b4]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x3dc
V  [libjvm.dylib+0x4fb6d0]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0xf0
V  [libjvm.dylib+0x3893c8]  ThreadDumpToFileDCmd::dumpToFile(Symbol*, Symbol*, char const*, bool, JavaThread*)+0xfc
V  [libjvm.dylib+0x38d93c]  DCmd::Executor::parse_and_execute(char const*, char, JavaThread*)+0x3a8
V  [libjvm.dylib+0x14b10c]  jcmd(AttachOperation*, attachStream*)+0xb8
V  [libjvm.dylib+0x148fd8]  AttachListenerThread::thread_entry(JavaThread*, JavaThread*)+0x37c
V  [libjvm.dylib+0x510a30]  JavaThread::thread_main_inner()+0x9c
V  [libjvm.dylib+0xb140c4]  Thread::call_run()+0xc8
V  [libjvm.dylib+0x8adbfc]  thread_native_entry(Thread*)+0x118
C  [libsystem_pthread.dylib+0x6f94]  _pthread_start+0x88
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jdk.internal.vm.ThreadSnapshot.create(Ljava/lang/Thread;)Ljdk/internal/vm/ThreadSnapshot;+0 java.base@26-internal
j  jdk.internal.vm.ThreadSnapshot.of(Ljava/lang/Thread;)Ljdk/internal/vm/ThreadSnapshot;+1 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThread(Ljava/lang/Thread;Ljdk/internal/vm/ThreadDumper$JsonWriter;)Z+5 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreads(Ljdk/internal/vm/ThreadContainer;Ljdk/internal/vm/ThreadDumper$JsonWriter;)V+95 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToJson(Ljdk/internal/vm/ThreadDumper$TextWriter;)V+64 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToFile(Ljava/lang/String;ZZ)[B+62 java.base@26-internal
j  jdk.internal.vm.ThreadDumper.dumpThreadsToJson(Ljava/lang/String;Z)[B+24 java.base@26-internal
v  ~StubRoutines::Stub Generator call_stub_stub 0x0000000114b44454

I ran this test 1000 times on a macos system but it didn't recreate. Core dump is not available.
Comments
There are two issues here and both are duplicates of other bugs. First the test timed-out (fixed by JDK-8366893): 2025-08-27T20:26:39.480348Z => 98713 of 100000 2025-08-27T20:26:40.481700Z => 98758 of 100000 2025-08-27T20:26:41.486782Z => 98808 of 100000 2025-08-27T20:26:42.493220Z => 98864 of 100000 2025-08-27T20:26:43.522669Z => 98914 of 100000 2025-08-27T20:26:44.532765Z => 98969 of 100000 2025-08-27T20:26:45.532943Z => 99017 of 100000 2025-08-27T20:26:46.535582Z => 99068 of 100000 Timeout signalled after 1200 seconds 2025-08-27T20:26:47.583322Z => 99120 of 100000 2025-08-27T20:26:48.602272Z => 99164 of 100000 2025-08-27T20:26:49.613581Z => 99206 of 100000 2025-08-27T20:26:50.664553Z => 99252 of 100000 Then when the jtreg timeout handler runs and the threaddump jcmd is invoked we run into JDK-8364343, i.e. while getting the stack trace of one of the virtual threads it gets mounted/unmounted.
12-09-2025

ILW=HLM=P3
02-09-2025