-
Bug
-
Resolution: Fixed
-
P1
-
10
-
b21
-
generic
-
linux
-
Verified
This test failure was spotted in the 2017-07-25 JDK10-hs nightly:
compiler/c2/Test8004741.java
Test failed due to SIGSEGV on Linux AArch64 64-bit Server VM.
Here is a snippet of the stack trace:
--------------- T H R E A D ---------------
Current thread (0x0000007fa81a2800): VMThread "VM Thread" [stack: 0x0000007f74359000,0x0000007f74459000] [id=1824]
Stack: [0x0000007f74359000,0x0000007f74459000], sp=0x0000007f74456d30, free space=1015k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xf8e8dc] JavaThread::send_thread_stop(oop)+0xac;; JavaThread::send_thread_stop(oop)+0xac
V [libjvm.so+0x1057d1c] VM_ThreadStop::doit()+0xac;; VM_ThreadStop::doit()+0xac
V [libjvm.so+0x1058bcc] VM_Operation::evaluate()+0x138;; VM_Operation::evaluate()+0x138
V [libjvm.so+0x1055bd8] VMThread::evaluate_operation(VM_Operation*)+0x134;; VMThread::evaluate_operation(VM_Operation*)+0x134
V [libjvm.so+0x1056700] VMThread::loop()+0x5e4;; VMThread::loop()+0x5e4
V [libjvm.so+0x1056914] VMThread::run()+0xd4;; VMThread::run()+0xd4
V [libjvm.so+0xd59d5c] thread_native_entry(Thread*)+0x118;; thread_native_entry(Thread*)+0x118
C [libpthread.so.0+0x7e2c] start_thread+0xb0
Normally I would start this bug out in in hotspot/compiler for initial
triage, but the crashing stack trace is very much runtime code so
hotspot/runtime for initial triage.
compiler/c2/Test8004741.java
Test failed due to SIGSEGV on Linux AArch64 64-bit Server VM.
Here is a snippet of the stack trace:
--------------- T H R E A D ---------------
Current thread (0x0000007fa81a2800): VMThread "VM Thread" [stack: 0x0000007f74359000,0x0000007f74459000] [id=1824]
Stack: [0x0000007f74359000,0x0000007f74459000], sp=0x0000007f74456d30, free space=1015k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xf8e8dc] JavaThread::send_thread_stop(oop)+0xac;; JavaThread::send_thread_stop(oop)+0xac
V [libjvm.so+0x1057d1c] VM_ThreadStop::doit()+0xac;; VM_ThreadStop::doit()+0xac
V [libjvm.so+0x1058bcc] VM_Operation::evaluate()+0x138;; VM_Operation::evaluate()+0x138
V [libjvm.so+0x1055bd8] VMThread::evaluate_operation(VM_Operation*)+0x134;; VMThread::evaluate_operation(VM_Operation*)+0x134
V [libjvm.so+0x1056700] VMThread::loop()+0x5e4;; VMThread::loop()+0x5e4
V [libjvm.so+0x1056914] VMThread::run()+0xd4;; VMThread::run()+0xd4
V [libjvm.so+0xd59d5c] thread_native_entry(Thread*)+0x118;; thread_native_entry(Thread*)+0x118
C [libpthread.so.0+0x7e2c] start_thread+0xb0
Normally I would start this bug out in in hotspot/compiler for initial
triage, but the crashing stack trace is very much runtime code so
hotspot/runtime for initial triage.
- relates to
-
JDK-8185345 VMOperationQueue::oops_do() is not thread-safe
-
- Closed
-
-
JDK-8180932 Parallelize safepoint cleanup
-
- Resolved
-
-
JDK-8185580 Refactor Threads::possibly_parallel_oops_do() to use Threads::parallel_java_threads_do()
-
- Resolved
-