JDK-8262894 : [macos_aarch64] SIGBUS in Assembler::ld_st2
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-03-02
  • Updated: 2022-05-30
  • Resolved: 2021-03-31
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 11 JDK 17
11.0.15Fixed 17 b16Fixed
Related Reports
Relates :  
JDK-8253795 - Implementation of JEP 391: macOS/AArch64 Port
Relates :  
JDK-8264240 - [macos_aarch64] enable appcds support after JDK-8263002
Relates :  
JDK-8287508 - The tests added to jdk-8 by 8235385 are to be ported to jdk-11
Relates :  
JDK-8235385 - Crash on aarch64 JDK due to long offset
Description
Testing https://github.com/openjdk/jdk/pull/2200 shows a crash in compiler/debug/VerifyAdapterSharing.java:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x00000001098d6d08, pid=52606, tid=9731
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-02-27-1954067.mikael.vidstedt.jdk-macosjib)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-02-27-1954067.mikael.vidstedt.jdk-macosjib, compiled mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0xd6d08]  Assembler::ld_st2(RegisterImpl*, Address const&, int, int, int)+0x254
#
# Core dump will be written. Default location: core.52606
#
# An error report file with more information is saved as:
# /System/Volumes/Data/mesos/work_dir/slaves/28992c6d-c35d-42fa-8099-898223bf183b-S11309/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/eda33d5b-1dda-4d91-8950-bd14dcc0ad66/runs/d5b4c242-6c0b-4944-b6a3-149ef19e75ae/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/0/hs_err_pid52606.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Comments
Fix Request(11u): This fixes a small issue with jep-391 backport. Applies almost clean. Macos-aarch64 only change, so pretty safe.
15-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/816 Date: 2022-02-09 21:35:38 +0000
09-02-2022
Changeset: 8a4a9117 Author: Anton Kozlov <akozlov@openjdk.org> Committer: Vladimir Kempik <vkempik@openjdk.org> Date: 2021-03-31 09:34:12 +0000 URL: https://git.openjdk.java.net/jdk/commit/8a4a9117
31-03-2021
(Oops, I have not clicked "Add" the comment yesterday) Thanks for looking at this! I extended the fix with the handling of the unsuccessful destroy_vm call and a fix for a similar case in DetachCurrentThread. Although it turned out destroy_vm does not fail.
30-03-2021
Here's the stack trace from the specific crash in the bug description (hs_err_pid52606.log) Stack: [0x000000016ae98000,0x000000016b09b000], sp=0x000000016b099bc0, free space=2054k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xd6d08] Assembler::ld_st2(RegisterImpl*, Address const&, int, int, int)+0x254 V [libjvm.dylib+0xd842f0] SharedRuntime::gen_i2c_adapter(MacroAssembler*, int, int, BasicType const*, VMRegPair const*)+0x110 V [libjvm.dylib+0xd84a58] SharedRuntime::generate_i2c2i_adapters(MacroAssembler*, int, int, BasicType const*, VMRegPair const*, AdapterFingerPrint*)+0x40 V [libjvm.dylib+0xd7b43c] AdapterHandlerLibrary::get_adapter0(methodHandle const&)+0x3e0 V [libjvm.dylib+0xd7ad6c] AdapterHandlerLibrary::get_adapter(methodHandle const&)+0x24 V [libjvm.dylib+0xbe2348] Method::make_adapters(methodHandle const&, Thread*)+0x20 V [libjvm.dylib+0x764750] InstanceKlass::link_methods(Thread*)+0x7c V [libjvm.dylib+0x76366c] InstanceKlass::link_class_impl(Thread*)+0x344 V [libjvm.dylib+0x763a6c] InstanceKlass::initialize_impl(Thread*)+0x98 V [libjvm.dylib+0xabc544] LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, Thread*)+0x7c V [libjvm.dylib+0x795db8] JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x90 V [libjvm.dylib+0x795eec] JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, Thread*)+0x58 V [libjvm.dylib+0xe920dc] JavaThread::invoke_shutdown_hooks()+0x80 V [libjvm.dylib+0xe922ec] Threads::destroy_vm()+0x1e8 V [libjvm.dylib+0x867408] jni_DestroyJavaVM+0xdc C [libjli.dylib+0x54a0] JavaMain+0xc5c C [libjli.dylib+0x7500] ThreadJavaMain+0xc C [libsystem_pthread.dylib+0x706c] _pthread_start+0x140
30-03-2021
Yes, I can see that now. It looks like "MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));" might be missing here as well: // Since this is not a JVM_ENTRY we have to set the thread state manually before entering. JavaThread* thread = JavaThread::current(); MACOS_AARCH64_ONLY(thread->enable_wx(WXWrite)); ThreadStateTransition::transition_from_native(thread, _thread_in_vm); if (Threads::destroy_vm()) { // Should not change thread state, VM is gone vm_created = 0; res = JNI_OK; return res; } else { ThreadStateTransition::transition(thread, _thread_in_vm, _thread_in_native); MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); res = JNI_ERR; return res; }
29-03-2021
I tried that first, and that specific code doesn't work because the ThreadWXEnable destructor depends on the thread still being attached, but it gets called after the thread is detached (when the __wx variable goes out of scope). There may be other ways of expressing/solving it though.
26-03-2021
The pattern I see most used in the code for WXWrite is: MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, thread));
26-03-2021
Potential fix: diff --git a/src/hotspot/share/prims/jni.cpp b/src/hotspot/share/prims/jni.cpp index e2e7799c26c..0d619157c46 100644 --- a/src/hotspot/share/prims/jni.cpp +++ b/src/hotspot/share/prims/jni.cpp @@ -3723,6 +3723,7 @@ static jint JNICALL jni_DestroyJavaVM_inner(JavaVM *vm) { // Since this is not a JVM_ENTRY we have to set the thread state manually before entering. JavaThread* thread = JavaThread::current(); + MACOS_AARCH64_ONLY(thread->enable_wx(WXWrite)); ThreadStateTransition::transition_from_native(thread, _thread_in_vm); if (Threads::destroy_vm()) { // Should not change thread state, VM is gone With that patch the CDS tests pass (when explicitly including CDS in the build).
26-03-2021
The issue is caused by a missing transition to WXWrite, triggered by combination of flags -Xcomp -XX:+VerifyAdapterSharing. The issue will also appear when a code is generated as preparation for shutdownHooks during execution of JNI DestroyJavaVM.
12-03-2021