JDK-8321379 : java/awt/font/TextLayout/FontLayoutStressTest.java crashes in G1ParScanThreadState::trim_queue_to_threshold processing JNI handles
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 22,24
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-12-05
  • Updated: 2025-02-25
  • Resolved: 2024-11-19
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 22
22Resolved
Related Reports
Duplicate :  
JDK-8331735 - UpcallLinker::on_exit races with GC when copying frame anchor
Relates :  
JDK-8320253 - G1: SIGSEGV in G1ParScanThreadState::trim_queue_to_threshold
Description
Extracted from JDK-8320253 because of different test and stack trace:

 java/awt/font/TextLayout/FontLayoutStressTest.java


# SIGSEGV (0xb) at pc=0x0000ffff90dbc5d4, pid=827397, tid=827401
#
# JRE version: Java(TM) SE Runtime Environment (22.0+26) (build 22-ea+26-2012)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22-ea+26-2012, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x7145d4] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x2190

<snip>

--------------- T H R E A D ---------------

Current thread (0x0000ffff8c05da60): WorkerThread "GC Thread#0" [id=827401, stack(0x0000ffff7346d000,0x0000ffff7366b000) (2040K)]

Stack: [0x0000ffff7346d000,0x0000ffff7366b000], sp=0x0000ffff73669280, free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x7145d4] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x2190 (klass.hpp:286)
V [libjvm.so+0x7324c4] G1ParCopyClosure<(G1Barrier)0, false>::do_oop(oopDesc**)+0x84 (g1ParScanThreadState.inline.hpp:53)
V [libjvm.so+0x8bb590] JNIHandleBlock::oops_do(OopClosure*)+0x60 (jniHandles.cpp:407)
V [libjvm.so+0x817848] JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x34 (javaThread.cpp:1352)
V [libjvm.so+0xcfc7a4] Thread::oops_do(OopClosure*, CodeBlobClosure*)+0xa4 (thread.cpp:434)
V [libjvm.so+0xd087d0] Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x10c (threads.cpp:1147)
V [libjvm.so+0x734e20] G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x80 (g1RootProcessor.cpp:180)
V [libjvm.so+0x734f24] G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x64 (g1RootProcessor.cpp:61)
V [libjvm.so+0x746e44] G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x24 (g1YoungCollector.cpp:654)
V [libjvm.so+0x747044] G1EvacuateRegionsBaseTask::work(unsigned int)+0x84 (g1YoungCollector.cpp:641)
V [libjvm.so+0xd9fbc8] WorkerThread::run()+0x98 (workerThread.cpp:69)
V [libjvm.so+0xcfcca8] Thread::call_run()+0xa8 (thread.cpp:220)
V [libjvm.so+0xb86998] thread_native_entry(Thread*)+0xd8 (os_linux.cpp:787)
C [libc.so.6+0x857d8] start_thread+0x2d8
JavaThread 0x0000ffff2c24cdc0 (nid = 827466) was being processed

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000190ed508220
Comments
I think this is caused by the issue I described in: https://bugs.openjdk.org/browse/JDK-8331735?focusedId=14716984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14716984
28-10-2024
[~mbaesken] yes it was linux-aarch64
29-08-2024
> I've also hit this in a personal mach5 job. Same test. Do you see this also on Linux aarch64 (most (all?) reports seem to be from this platform).
28-08-2024
I've also hit this in a personal mach5 job. Same test.
28-08-2024
We've seen the same/similar crash in JDK24 , also on Linux aarch64 (test is again java/awt/font/TextLayout/FontLayoutStressTest ) : # SIGSEGV (0xb) at pc=0x0000ffff8b930624, pid=3199208, tid=3199638 # # JRE version: OpenJDK Runtime Environment (24.0) (build 24-internal-adhoc.jenkinsi.jdk) # Java VM: OpenJDK 64-Bit Server VM (24-internal-adhoc.jenkinsi.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x730624] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x33f4 Stack: [0x0000fffed4aa4000,0x0000fffed4ca2000], sp=0x0000fffed4ca04c0, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x730624] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x33f4 (oop.inline.hpp:196) V [libjvm.so+0x7663fc] G1ParEvacuateFollowersClosure::do_void()+0x4c (g1ParScanThreadState.inline.hpp:60) V [libjvm.so+0x766978] G1EvacuateRegionsTask::evacuate_live_objects(G1ParScanThreadState*, unsigned int)+0x78 (g1YoungCollector.cpp:602) V [libjvm.so+0x7645f0] G1EvacuateRegionsBaseTask::work(unsigned int)+0xa0 (g1YoungCollector.cpp:652) V [libjvm.so+0xe4e6c8] WorkerThread::run()+0x98 (workerThread.cpp:70) V [libjvm.so+0xd9d858] Thread::call_run()+0xa8 (thread.cpp:225) V [libjvm.so+0xba467c] thread_native_entry(Thread*)+0xdc (os_linux.cpp:858) C [libc.so.6+0x80698] start_thread+0x2d8 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000100 Registers are like this: R0=0x0000ffff8b5f6010 R1=0x0000000000000000 R2=0x0000000000000000 R3=0x0000000000000001 R4=0x0000000000000000 R5=0x0000000000000001 R6=0x0000ffff8c525000 R7=0x0000fffe640010a0 R8=0x0000fffe7c0022e0 R9=0xfb4cfb00010018b0 R10=0x0000000000000000 R11=0x0000000000000000 R12=0x000000fc00000001 R13=0x0000ffff842684c0 R14=0x4068000000000000 R15=0x00000000fb4cfaf0 R16=0xfb4d0a88fb400150 R17=0x00000000fb2017b8 R18=0x0000000000000000 R19=0x0000fffe640016c0 R20=0x000000000001fffe R21=0x0000ffff8c5aaa70 R22=0x0000ffff8c543998 R23=0x0000000000000000 R24=0x0000000000000000 R25=0x0000ffff8c525000 R26=0x0000000000000000 R27=0x00000000fa6f254d R28=0x00000000fda00428 R29=0x0000fffed4ca04c0 R30=0x0000ffff8b931178 We crash at the load ldr x2, [x1, #0x100] (with R1 = x1 having value 0x0000000000000000 it is not a surprise that we crash) Could we maybe add some guarantee/check for this to get a better error behavior ?
07-08-2024
seems some other people saw (see ?) this too : https://github.com/adoptium/adoptium-support/issues/959
06-08-2024
Moved here from JDK-8320253: Daniel Daugherty added a comment - 2023-11-22 15:11 - edited Here's hs_err_pid file snippets for the jdk-22+26-2012-tier3 sighting: java/awt/font/TextLayout/FontLayoutStressTest.java # SIGSEGV (0xb) at pc=0x0000ffff90dbc5d4, pid=827397, tid=827401 # # JRE version: Java(TM) SE Runtime Environment (22.0+26) (build 22-ea+26-2012) # Java VM: Java HotSpot(TM) 64-Bit Server VM (22-ea+26-2012, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x7145d4] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x2190 <snip> --------------- T H R E A D --------------- Current thread (0x0000ffff8c05da60): WorkerThread "GC Thread#0" [id=827401, stack(0x0000ffff7346d000,0x0000ffff7366b000) (2040K)] Stack: [0x0000ffff7346d000,0x0000ffff7366b000], sp=0x0000ffff73669280, free space=2032k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7145d4] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x2190 (klass.hpp:286) V [libjvm.so+0x7324c4] G1ParCopyClosure<(G1Barrier)0, false>::do_oop(oopDesc**)+0x84 (g1ParScanThreadState.inline.hpp:53) V [libjvm.so+0x8bb590] JNIHandleBlock::oops_do(OopClosure*)+0x60 (jniHandles.cpp:407) V [libjvm.so+0x817848] JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x34 (javaThread.cpp:1352) V [libjvm.so+0xcfc7a4] Thread::oops_do(OopClosure*, CodeBlobClosure*)+0xa4 (thread.cpp:434) V [libjvm.so+0xd087d0] Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x10c (threads.cpp:1147) V [libjvm.so+0x734e20] G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0x80 (g1RootProcessor.cpp:180) V [libjvm.so+0x734f24] G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x64 (g1RootProcessor.cpp:61) V [libjvm.so+0x746e44] G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x24 (g1YoungCollector.cpp:654) V [libjvm.so+0x747044] G1EvacuateRegionsBaseTask::work(unsigned int)+0x84 (g1YoungCollector.cpp:641) V [libjvm.so+0xd9fbc8] WorkerThread::run()+0x98 (workerThread.cpp:69) V [libjvm.so+0xcfcca8] Thread::call_run()+0xa8 (thread.cpp:220) V [libjvm.so+0xb86998] thread_native_entry(Thread*)+0xd8 (os_linux.cpp:787) C [libc.so.6+0x857d8] start_thread+0x2d8 JavaThread 0x0000ffff2c24cdc0 (nid = 827466) was being processed siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000190ed508220
30-12-2023
Can not reproduce after 22k iterations.
20-12-2023
Does not reproduce after 13k iterations with latest, and 9k iterations with the exact build this occurred; test runs evenly split between aarch64 and x64.
18-12-2023