JDK-8316392 : compiler/interpreter/TestVerifyStackAfterDeopt.java failed with SIGBUS in PcDescContainer::find_pc_desc_internal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17.0.9,21,22
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2023-09-16
  • Updated: 2024-01-22
  • Resolved: 2023-11-14
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 17 JDK 21 JDK 22
17.0.11-oracleFixed 21.0.3-oracleFixed 22 b24Fixed
Related Reports
Relates :  
JDK-8307817 - AARCH64: make macOS W^X locking more fine grained
Relates :  
JDK-8302736 - Major performance regression in Math.log on aarch64
Sub Tasks
JDK-8317448 :  
ProblemList compiler/interpreter/TestVerifyStackAfterDeopt.java on macosx-aarch64 in Xcomp - Resolved
Description
The following test failed in the JDK22 CI:

compiler/interpreter/TestVerifyStackAfterDeopt.java

Here's a snippet from the log file:

#section:main
----------messages:(6/811)----------
command: main -XX:+IgnoreUnrecognizedVMOptions -XX:TieredStopAtLevel=1 -XX:AllocatePrefetchLines=1 -XX:AllocateInstancePrefetchLines=1 -XX:AllocatePrefetchStepSize=16 -XX:AllocatePrefetchDistance=1 -XX:MinTLABSize=1k -XX:TLABSize=1k -XX:+DeoptimizeALot -XX:+VerifyStack compiler.interpreter.TestVerifyStackAfterDeopt
reason: User specified action: run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:TieredStopAtLevel=1 -XX:AllocatePrefetchLines=1 -XX:AllocateInstancePrefetchLines=1 -XX:AllocatePrefetchStepSize=16 -XX:AllocatePrefetchDistance=1 -XX:MinTLABSize=1k -XX:TLABSize=1k -XX:+DeoptimizeALot -XX:+VerifyStack compiler.interpreter.TestVerifyStackAfterDeopt 
started: Sat Sep 16 11:46:03 GMT 2023
Mode: othervm [/othervm specified]
finished: Sat Sep 16 11:46:10 GMT 2023
elapsed time (seconds): 6.778
----------configuration:(0/0)----------
----------System.out:(19/1143)----------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x00000001077fcf6c, pid=83896, tid=6915
#
# JRE version: Java(TM) SE Runtime Environment (22.0+16) (fastdebug build 22-ea+16-1142)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+16-1142, compiled mode, emulated-client, sharing, tiered, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0xff4f6c]  PcDescContainer::find_pc_desc_internal(unsigned char*, bool, PcDescSearch const&)+0x76c
#
# Core dump will be written. Default location: core.83896
#
# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S176544/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/bd0a4977-ec35-4387-8f72-a036635a283d/runs/93184247-9afb-4c48-848f-f631c880deda/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_compiler_2/scratch/3/hs_err_pid83896.log
[0.216s][warning][os] Loading hsdis library failed
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(1/90)----------
Java HotSpot(TM) 64-Bit Server VM warning: AllocatePrefetchDistance must be multiple of 8
----------rerun:(52/7087)*----------

Here's the crashing thread's stack:

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

Current thread (0x000000011d80c010):  JavaThread "main"             [_thread_in_Java, id=6915, stack(0x000000016b6b8000,0x000000016b8bb000) (2060K)]

Stack: [0x000000016b6b8000,0x000000016b8bb000],  sp=0x000000016b8b7b80,  free space=2046k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xff4f6c]  PcDescContainer::find_pc_desc_internal(unsigned char*, bool, PcDescSearch const&)+0x76c
V  [libjvm.dylib+0x639dac]  CompiledMethod::scope_desc_at(unsigned char*)+0x70
V  [libjvm.dylib+0x7db870]  frame::describe(FrameValues&, int, RegisterMap const*)+0x84c
V  [libjvm.dylib+0xa46b4c]  JavaThread::print_frame_layout(int, bool)+0x264
V  [libjvm.dylib+0x6e8ac0]  Deoptimization::unpack_frames(JavaThread*, int)+0x1f8
v  ~DeoptimizationBlob 0x0000000110a81120
j  java.lang.invoke.MethodTypeForm.<init>(Ljava/lang/invoke/MethodType;)V+235 java.base@22-ea
J 219 c1 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (109 bytes) @ 0x0000000110bbf448 [0x0000000110bbf000+0x0000000000000448]
J 273 c1 java.lang.invoke.MethodType.methodType(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (69 bytes) @ 0x0000000110c01a98 [0x0000000110c01940+0x0000000000000158]
J 210 c1 java.lang.invoke.MethodTypeForm.canonicalize(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/MethodType; java.base@22-ea (59 bytes) @ 0x0000000110bb9304 [0x0000000110bb9200+0x0000000000000104]
J 219 c1 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (109 bytes) @ 0x0000000110bbf3d8 [0x0000000110bbf000+0x00000000000003d8]
J 272 c1 java.lang.invoke.MethodType.insertParameterTypes(I[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; java.base@22-ea (121 bytes) @ 0x0000000110c00918 [0x0000000110c00540+0x00000000000003d8]
J 271 c1 java.lang.invoke.MethodType.invokerType()Ljava/lang/invoke/MethodType; java.base@22-ea (9 bytes) @ 0x0000000110c000f8 [0x0000000110c00040+0x00000000000000b8]
j  java.lang.invoke.DirectMethodHandle.makePreparedFieldLambdaForm(BZI)Ljava/lang/invoke/LambdaForm;+434 java.base@22-ea
J 234 c1 java.lang.invoke.DirectMethodHandle.preparedFieldLambdaForm(BZLjava/lang/Class;)Ljava/lang/invoke/LambdaForm; java.base@22-ea (48 bytes) @ 0x0000000110bd238c [0x0000000110bd2280+0x000000000000010c]
J 230 c1 java.lang.invoke.DirectMethodHandle.preparedFieldLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm; java.base@22-ea (180 bytes) @ 0x0000000110bcea94 [0x0000000110bce940+0x0000000000000154]
J 226 c1 java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle; java.base@22-ea (275 bytes) @ 0x0000000110bc9ae8 [0x0000000110bc9840+0x00000000000002a8]
J 225 c1 java.lang.invoke.DirectMethodHandle.make(Ljava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/DirectMethodHandle; java.base@22-ea (21 bytes) @ 0x0000000110bc925c [0x0000000110bc91c0+0x000000000000009c]
J 157 c1 java.lang.invoke.MethodHandles$Lookup.getDirectFieldCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/MethodHandle; java.base@22-ea (67 bytes) @ 0x0000000110b92bc4 [0x0000000110b92ac0+0x0000000000000104]
J 153 c1 java.lang.invoke.MethodHandles$Lookup.unreflectField(Ljava/lang/reflect/Field;Z)Ljava/lang/invoke/MethodHandle; java.base@22-ea (126 bytes) @ 0x0000000110b90be4 [0x0000000110b909c0+0x0000000000000224]
J 152 c1 java.lang.invoke.MethodHandles$Lookup.unreflectGetter(Ljava/lang/reflect/Field;)Ljava/lang/invoke/MethodHandle; java.base@22-ea (7 bytes) @ 0x0000000110b905f4 [0x0000000110b90540+0x00000000000000b4]
j  java.lang.invoke.MethodHandleImpl$1.unreflectField(Ljava/lang/reflect/Field;Z)Ljava/lang/invoke/MethodHandle;+18 java.base@22-ea
j  jdk.internal.reflect.MethodHandleAccessorFactory.newFieldAccessor(Ljava/lang/reflect/Field;Z)Ljdk/internal/reflect/FieldAccessorImpl;+63 java.base@22-ea
J 104 c1 jdk.internal.reflect.ReflectionFactory.newFieldAccessor(Ljava/lang/reflect/Field;Z)Ljdk/internal/reflect/FieldAccessor; java.base@22-ea (80 bytes) @ 0x0000000110b76fcc [0x0000000110b76e40+0x000000000000018c]
J 103 c1 java.lang.reflect.Field.acquireFieldAccessor()Ljdk/internal/reflect/FieldAccessor; java.base@22-ea (46 bytes) @ 0x0000000110b76668 [0x0000000110b76580+0x00000000000000e8]
J 88 c1 java.lang.reflect.Field.getInt(Ljava/lang/Object;)I java.base@22-ea (39 bytes) @ 0x0000000110b6cd7c [0x0000000110b6cbc0+0x00000000000001bc]
j  java.lang.invoke.MethodHandleNatives.verifyConstants()Z+48 java.base@22-ea
j  java.lang.invoke.MethodHandleNatives.<clinit>()V+85 java.base@22-ea
v  ~StubRoutines::call_stub 0x00000001109a816c
V  [libjvm.dylib+0xa0af28]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x65c
V  [libjvm.dylib+0x9c0080]  InstanceKlass::call_class_initializer(JavaThread*)+0x3e8
V  [libjvm.dylib+0x9bd294]  InstanceKlass::initialize_impl(JavaThread*)+0x918
V  [libjvm.dylib+0x9bc904]  InstanceKlass::initialize(JavaThread*)+0x30
V  [libjvm.dylib+0x13164f8]  Threads::initialize_jsr292_core_classes(JavaThread*)+0x52c
V  [libjvm.dylib+0x1316e1c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x8d8
V  [libjvm.dylib+0xb2b380]  JNI_CreateJavaVM+0x70
C  [libjli.dylib+0xa650]  JavaMain+0x104
C  [libjli.dylib+0xd4c4]  ThreadJavaMain+0xc
C  [libsystem_pthread.dylib+0x726c]  _pthread_start+0x94
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~DeoptimizationBlob 0x0000000110a810f4
j  java.lang.invoke.MethodTypeForm.<init>(Ljava/lang/invoke/MethodType;)V+235 java.base@22-ea
J 219 c1 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (109 bytes) @ 0x0000000110bbf448 [0x0000000110bbf000+0x0000000000000448]
J 273 c1 java.lang.invoke.MethodType.methodType(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (69 bytes) @ 0x0000000110c01a98 [0x0000000110c01940+0x0000000000000158]
J 210 c1 java.lang.invoke.MethodTypeForm.canonicalize(Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/MethodType; java.base@22-ea (59 bytes) @ 0x0000000110bb9304 [0x0000000110bb9200+0x0000000000000104]
J 219 c1 java.lang.invoke.MethodType.makeImpl(Ljava/lang/Class;[Ljava/lang/Class;Z)Ljava/lang/invoke/MethodType; java.base@22-ea (109 bytes) @ 0x0000000110bbf3d8 [0x0000000110bbf000+0x00000000000003d8]
J 272 c1 java.lang.invoke.MethodType.insertParameterTypes(I[Ljava/lang/Class;)Ljava/lang/invoke/MethodType; java.base@22-ea (121 bytes) @ 0x0000000110c00918 [0x0000000110c00540+0x00000000000003d8]
J 271 c1 java.lang.invoke.MethodType.invokerType()Ljava/lang/invoke/MethodType; java.base@22-ea (9 bytes) @ 0x0000000110c000f8 [0x0000000110c00040+0x00000000000000b8]
j  java.lang.invoke.DirectMethodHandle.makePreparedFieldLambdaForm(BZI)Ljava/lang/invoke/LambdaForm;+434 java.base@22-ea
J 234 c1 java.lang.invoke.DirectMethodHandle.preparedFieldLambdaForm(BZLjava/lang/Class;)Ljava/lang/invoke/LambdaForm; java.base@22-ea (48 bytes) @ 0x0000000110bd238c [0x0000000110bd2280+0x000000000000010c]
J 230 c1 java.lang.invoke.DirectMethodHandle.preparedFieldLambdaForm(Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/LambdaForm; java.base@22-ea (180 bytes) @ 0x0000000110bcea94 [0x0000000110bce940+0x0000000000000154]
J 226 c1 java.lang.invoke.DirectMethodHandle.make(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Ljava/lang/Class;)Ljava/lang/invoke/DirectMethodHandle; java.base@22-ea (275 bytes) @ 0x0000000110bc9ae8 [0x0000000110bc9840+0x00000000000002a8]
J 225 c1 java.lang.invoke.DirectMethodHandle.make(Ljava/lang/Class;Ljava/lang/invoke/MemberName;)Ljava/lang/invoke/DirectMethodHandle; java.base@22-ea (21 bytes) @ 0x0000000110bc925c [0x0000000110bc91c0+0x000000000000009c]
J 157 c1 java.lang.invoke.MethodHandles$Lookup.getDirectFieldCommon(BLjava/lang/Class;Ljava/lang/invoke/MemberName;Z)Ljava/lang/invoke/MethodHandle; java.base@22-ea (67 bytes) @ 0x0000000110b92bc4 [0x0000000110b92ac0+0x0000000000000104]
J 153 c1 java.lang.invoke.MethodHandles$Lookup.unreflectField(Ljava/lang/reflect/Field;Z)Ljava/lang/invoke/MethodHandle; java.base@22-ea (126 bytes) @ 0x0000000110b90be4 [0x0000000110b909c0+0x0000000000000224]
J 152 c1 java.lang.invoke.MethodHandles$Lookup.unreflectGetter(Ljava/lang/reflect/Field;)Ljava/lang/invoke/MethodHandle; java.base@22-ea (7 bytes) @ 0x0000000110b905f4 [0x0000000110b90540+0x00000000000000b4]
j  java.lang.invoke.MethodHandleImpl$1.unreflectField(Ljava/lang/reflect/Field;Z)Ljava/lang/invoke/MethodHandle;+18 java.base@22-ea
j  jdk.internal.reflect.MethodHandleAccessorFactory.newFieldAccessor(Ljava/lang/reflect/Field;Z)Ljdk/internal/reflect/FieldAccessorImpl;+63 java.base@22-ea
J 104 c1 jdk.internal.reflect.ReflectionFactory.newFieldAccessor(Ljava/lang/reflect/Field;Z)Ljdk/internal/reflect/FieldAccessor; java.base@22-ea (80 bytes) @ 0x0000000110b76fcc [0x0000000110b76e40+0x000000000000018c]
J 103 c1 java.lang.reflect.Field.acquireFieldAccessor()Ljdk/internal/reflect/FieldAccessor; java.base@22-ea (46 bytes) @ 0x0000000110b76668 [0x0000000110b76580+0x00000000000000e8]
J 88 c1 java.lang.reflect.Field.getInt(Ljava/lang/Object;)I java.base@22-ea (39 bytes) @ 0x0000000110b6cd7c [0x0000000110b6cbc0+0x00000000000001bc]
j  java.lang.invoke.MethodHandleNatives.verifyConstants()Z+48 java.base@22-ea
j  java.lang.invoke.MethodHandleNatives.<clinit>()V+85 java.base@22-ea
v  ~StubRoutines::call_stub 0x00000001109a816c

siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr: 0x0000000110bbedb8

I'm starting this bug off in hotspot/compiler for initial triage since
it is a compiler test.
Comments
Fix request [17u] I backport this for parity with 17.0.11-oracle. Medium risk, compiler change but small and limited to one platform. Clean backport from 21.0.3. SAP nightly testing passed.
22-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2074 Date: 2023-12-21 16:51:02 +0000
21-12-2023
Fix request [21u] I backport this for parity with 21.0.3-oracle. Medium risk, compiler change but small and limited to one platform. Fixes an issue also backported to 17. Clean backport except for ProblemList. SAP nighlty testing passed.
17-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/32 Date: 2023-12-14 19:44:49 +0000
14-12-2023
Changeset: 58af9aee Author: Tobias Holenstein <tholenstein@openjdk.org> Date: 2023-11-14 16:17:34 +0000 URL: https://git.openjdk.org/jdk/commit/58af9aeeb07b7a392a8fbf04ef5cb2607b7b2462
14-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16308 Date: 2023-10-23 11:43:52 +0000
13-11-2023
We currently have 14 sightings of compiler/interpreter/TestVerifyStackAfterDeopt.java failing in the JDK22 CI. All of these failures are on macosx-aarch64 in -Xcomp mode and I need to do something to reduce the noise even though there are discussions about a possible fix.
03-10-2023
Always updating the cache and running with -XX:+DeoptimizeALot -XX:+VerifyStack reproduces this reliably with any test: diff --git a/src/hotspot/share/code/nmethod.cpp b/src/hotspot/share/code/nmethod.cpp index 060d5ba080d..e41730f809b 100644 --- a/src/hotspot/share/code/nmethod.cpp +++ b/src/hotspot/share/code/nmethod.cpp @@ -2075,6 +2075,7 @@ PcDesc* PcDescContainer::find_pc_desc_internal(address pc, bool approximate, con // (This as an almost 100% hit rate.) PcDesc* res = _pc_desc_cache.find_pc_desc(pc_offset, approximate); if (res != nullptr) { + _pc_desc_cache.add_pc_desc(res); assert(res == linear_search(search, pc_offset, approximate), "cache ok"); return res; } And FTR, I found unrelated JDK-8316422 when investigating this.
20-09-2023
ILW = SIGBUS due to missing ThreadWXEnable, with single test and -XX:+DeoptimizeALot -XX:+VerifyStack, no workaround = HLH = P2
20-09-2023
Right, I agree. [~tholenstein], could you please have a look?
20-09-2023
Given we don't want to reinstate the WXWrite in VM_LEAF_BASE macro I presume we need to figure out where in that stack it should be added. In JDK-8302736 they did try to account for this cache in src/hotspot/share/runtime/sharedRuntime.cpp in SharedRuntime::raw_exception_handler_for_return_address: // write lock needed because we might update the pc desc cache via PcDescCache::add_pc_desc MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, current)); But this game of whack-a-mole with WXWrite really needs to stop.
20-09-2023
This fixes the issue: diff --git a/src/hotspot/share/runtime/interfaceSupport.inline.hpp b/src/hotspot/share/runtime/interfaceSupport.inline.hpp index 9de1f8126d1..9a87b65554a 100644 --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp @@ -260,6 +260,8 @@ class VMNativeEntryWrapper { #define VM_LEAF_BASE(result_type, header) \ debug_only(NoHandleMark __hm;) \ + MACOS_AARCH64_ONLY(ThreadWXEnable __wx2(WXWrite, \ + JavaThread::current())); \ os::verify_stack_alignment(); \ /* begin of body */ So it seems to be a regression from JDK-8302736.
20-09-2023
Similar to JDK-8304725, it's a missing ThreadWXEnable.
19-09-2023
I can't explain how (must be timing) but this is triggered by the fix for JDK-8315789 in jdk-22+15-1135. I verified by backing out the change.
19-09-2023