JDK-8293328 : compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java fails with SIGSEGV in JVM_handle_linux_signal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 20
  • Priority: P2
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: aarch64
  • Submitted: 2022-09-02
  • Updated: 2022-09-08
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 20
20Unresolved
Description
The following test failed in the JDK20 CI:

compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.java

Here's a snippet from the log file:

#section:main
----------messages:(4/453)----------
command: main -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 compiler.classUnloading.methodUnloading.TestOverloadCompileQueues
reason: User specified action: run main/othervm/timeout=300 -XX:TieredCompileTaskTimeout=1000 -XX:CompileThresholdScaling=0.001 -XX:CICompilerCount=2 compiler.classUnloading.methodUnloading.TestOverloadCompileQueues 
Mode: othervm [/othervm specified]
elapsed time (seconds): 17.078
----------configuration:(0/0)----------
----------System.out:(18/1393)----------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000fffd1cb511d0, pid=3731595, tid=3731622
#
# JRE version: Java(TM) SE Runtime Environment (20.0+14) (fastdebug build 20-ea+14-893)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+14-893, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x16611d0]  JVM_handle_linux_signal+0x240
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S78636/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2e23815e-f75c-4418-9c12-3416cc3bb6ab/runs/a79aa4cb-2db4-4a4f-b88e-759cb052c4a9/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_compiler_all_gcs/scratch/3/core.3731595)
#
# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S78636/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/2e23815e-f75c-4418-9c12-3416cc3bb6ab/runs/a79aa4cb-2db4-4a4f-b88e-759cb052c4a9/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_compiler_all_gcs/scratch/3/hs_err_pid3731595.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(38/6275)*----------


Here's the crashing thread's stack:

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

Current thread (0x0000fffd144855a0):  JavaThread "MainThread" [_thread_in_Java, id=3731622, stack(0x0000fffcfc1a0000,0x0000fffcfc3a0000)]

Stack: [0x0000fffcfc1a0000,0x0000fffcfc3a0000],  sp=0x0000fffcfc39b980,  free space=2030k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x16611d0]  JVM_handle_linux_signal+0x240  (signals_posix.cpp:637)
C  [linux-vdso.so.1+0x5d0]  __kernel_rt_sigreturn+0x0
[error occurred during error reporting (printing native stack), id 0xe0000000, Internal Error (/opt/mach5/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S78846/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/159a4a25-1b00-46c7-b9e2-cc86b002d32e/runs/c5f9b0ab-ea28-4e8b-b517-62dcf944e3b7/workspace/open/src/hotspot/share/utilities/elfFile.cpp:536)]


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0xfffffffdfffffffe


There's not enough of a stack to make a good guess at where
to start this bug. Since the failing test is in compiler/classUnloading,
I'm starting this bug in hotspot/compiler for initial triage.
Comments
According to the %lr value in the core dump, we were here before the crash: 0xfffcfd10afe8: ldr x8, [x28, #960] 0xfffcfd10afec: ldr wzr, [x8] 0xfffcfd10aff0: ldrb w8, [x28, #984] 0xfffcfd10aff4: cbz x8, 0xfffcfd10b00c 0xfffcfd10aff8: mov x8, #0xf4f0 // #62704 0xfffcfd10affc: movk x8, #0x1c39, lsl #16 0xfffcfd10b000: movk x8, #0xfffd, lsl #32 0xfffcfd10b004: mov x0, x28 0xfffcfd10b008: blr x8 which is a call to JavaThread::verify_cross_modify_fence_failure() coming from MacroAssembler::read_polling_page().
08-09-2022
ILW = crash, regression; intermittent so far; no workaround = HLH = P2
04-09-2022
Based on the timing, possibly related to JDK-8293327.
04-09-2022
The failure did NOT reproduce in the next Tier3: jdk-20+14-896-tier3
03-09-2022