JDK-8266889 : [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-05-11
  • Updated: 2024-02-29
  • Resolved: 2021-07-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 11 JDK 17 JDK 18
11.0.15Fixed 17 b31Fixed 18Fixed
Related Reports
Relates :  
JDK-8265292 - [macos_aarch64] java/foreign/TestDowncall.java crashes with SIGBUS
Relates :  
JDK-8327036 - [macosx-aarch64] SIGBUS in MarkActivationClosure::do_code_blob reached from Unsafe_CopySwapMemory0
Relates :  
JDK-8266742 - Check W^X state on possible safepoint
Description
Intermittent, looks like it requires at least -XX:+TieredCompilation. Have only been seen in macosx-aarch64 so far.

Sample output:

# Problematic frame:
# V  [libjvm.dylib+0xecb800]  MarkActivationClosure::do_code_blob(CodeBlob*)+0x74
...
Current thread (0x000000013082ec20):  JavaThread "MainThread" [_thread_in_vm, id=23555, stack(0x000000016e0cc000,0x000000016e2cf000)]

Stack: [0x000000016e0cc000,0x000000016e2cf000],  sp=0x000000016e2cce30,  free space=2051k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xecb800]  MarkActivationClosure::do_code_blob(CodeBlob*)+0x74
V  [libjvm.dylib+0xf271e8]  JavaThread::nmethods_do(CodeBlobClosure*)+0xe0
V  [libjvm.dylib+0x7523fc]  HandshakeOperation::do_handshake(JavaThread*)+0x70
V  [libjvm.dylib+0x753dc4]  HandshakeState::process_self_inner()+0x244
V  [libjvm.dylib+0x753a94]  HandshakeState::process_by_self()+0x134
V  [libjvm.dylib+0xdec9e4]  SafepointMechanism::process_if_requested_slow(JavaThread*)+0x30
V  [libjvm.dylib+0x2af970]  ThreadBlockInVM::~ThreadBlockInVM()+0xf4
V  [libjvm.dylib+0xacf0a8]  JvmtiRawMonitor::simple_wait(Thread*, long)+0x1e4
V  [libjvm.dylib+0xacf478]  JvmtiRawMonitor::raw_wait(long, Thread*)+0x64
V  [libjvm.dylib+0xaa76e4]  JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, long)+0x64
C  [libbi04t002.dylib+0x977c]  syncDebuggeeStatus(JNIEnv_*, _jvmtiEnv*, int)+0x574
C  [libbi04t002.dylib+0x91d0]  Java_nsk_share_jvmti_DebugeeClass_checkStatus+0x64
J 4797  nsk.share.jvmti.DebugeeClass.checkStatus(I)I (0 bytes) @ 0x0000000119714a44 [0x0000000119714940+0x0000000000000104]
C  0x0000000125222928

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 4797  nsk.share.jvmti.DebugeeClass.checkStatus(I)I (0 bytes) @ 0x0000000119714a44 [0x0000000119714940+0x0000000000000104]
j  nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.runIt([Ljava/lang/String;Ljava/io/PrintStream;)I+40
j  nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.run([Ljava/lang/String;Ljava/io/PrintStream;)I+9
j  nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.main([Ljava/lang/String;)V+9
v  ~StubRoutines::call_stub
J 4597  jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-internal (0 bytes) @ 0x00000001196cfaf0 [0x00000001196cfa00+0x00000000000000f0]
J 4595 c1 jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-internal (150 bytes) @ 0x0000000111eb1bb4 [0x0000000111eaf280+0x0000000000002934]
J 4593 c1 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-internal (10 bytes) @ 0x0000000111eb4be0 [0x0000000111eb4980+0x0000000000000260]
J 4559 c1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-internal (65 bytes) @ 0x0000000111f077d4 [0x0000000111f06d40+0x0000000000000a94]
J 4543 c1 com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V (476 bytes) @ 0x0000000111f0d274 [0x0000000111f0a200+0x0000000000003074]
J 4539 c1 java.lang.Thread.run()V java.base@17-internal (17 bytes) @ 0x0000000111f98250 [0x0000000111f97fc0+0x0000000000000290]
v  ~StubRoutines::call_stub
Comments
Fix Request (11u): This fixes small issue in jep-391 backport, not applying cleanly. Macos-aarch64 only fix, so pretty safe Also to be on par with Oracle
15-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/817 Date: 2022-02-10 07:08:28 +0000
10-02-2022
Changeset: 381bd621 Author: Anton Kozlov <akozlov@openjdk.org> Date: 2021-07-14 10:36:04 +0000 URL: https://git.openjdk.java.net/jdk17/commit/381bd621074a13cc2f260c18371c956bc48abd4d
14-07-2021
Do you mean RawMonitorEnter vs RawMonitorWait? It could be a matter of what thread get to the transition first. More runs may show different results.
23-06-2021
I get a slightly different stack trace: /Volumes/Work/tests/jtreg/jtreg/bin/jtreg -a -nr -jdk:./build/macosx-aarch64-server-fastdebug/images/jdk/ -nativepath:/Volumes/Work/bugs/8266889/jdk/build/macosx-aarch64-server-fastdebug/support/test/hotspot/jtreg/native/lib/ -exclude:/Volumes/Work/bugs/8266889/jdk/test/hotspot/jtreg/ProblemList.txt -verbose:summary -retain:fail -vmoption:-XX:+AssertWXAtThreadSync test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 Stack: [0x000000016fbd4000,0x000000016fdd7000], sp=0x000000016fdd5be0, free space=2054k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x10b247c] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5d0 V [libjvm.dylib+0x10b2b44] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40 V [libjvm.dylib+0x519f0c] report_vm_error(char const*, int, char const*, char const*, ...)+0x80 V [libjvm.dylib+0x41fa7c] ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState)+0x15c V [libjvm.dylib+0x8ee9f0] ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0xb0 V [libjvm.dylib+0xab0580] JvmtiRawMonitor::raw_enter(Thread*)+0xb4 V [libjvm.dylib+0xa8aa84] JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*)+0x68 C [libbi04t002.dylib+0x9824] syncDebuggeeStatus(JNIEnv_*, _jvmtiEnv*, int)+0x44 C [libbi04t002.dylib+0x97a8] Java_nsk_share_jvmti_DebugeeClass_checkStatus+0x64 j nsk.share.jvmti.DebugeeClass.checkStatus(I)I+0 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.runIt([Ljava/lang/String;Ljava/io/PrintStream;)I+40 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.run([Ljava/lang/String;Ljava/io/PrintStream;)I+9 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.main([Ljava/lang/String;)V+9 v ~StubRoutines::call_stub V [libjvm.dylib+0x7e37f0] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4d0 V [libjvm.dylib+0xdb8608] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, JavaThread*)+0xf58 V [libjvm.dylib+0xdb755c] Reflection::invoke_method(oop, Handle, objArrayHandle, JavaThread*)+0x2cc V [libjvm.dylib+0x91bce0] JVM_InvokeMethod+0x44c j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@18-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+133 java.base@18-internal j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base@18-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base@18-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base@18-internal v ~StubRoutines::call_stub
22-06-2021
I was able to reproduce an issue with assert and the stack trace with jtreg/bin/jtreg -a -nr -testjdk:/Users/tester/anton/jdk-fastdebug -nativepath:/Users/tester/anton/jdk-fastdebug-test/hotspot/jtreg/native -exclude:/Users/tester/anton/openjdk/test/hotspot/jtreg/ProblemList.txt -verbose:summary -retain:fail -vmoption:-XX:+AssertWXAtThreadSync /Users/tester/anton/openjdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 V [libjvm.dylib+0x10f6bdc] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5d8 V [libjvm.dylib+0x10f729c] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40 V [libjvm.dylib+0x52fe80] report_vm_error(char const*, int, char const*, char const*, ...)+0x80 V [libjvm.dylib+0x423cfc] ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState)+0x15c V [libjvm.dylib+0x436510] ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*)+0xb0 V [libjvm.dylib+0xaeec68] JvmtiRawMonitor::simple_wait(Thread*, long)+0x174 V [libjvm.dylib+0xaef0a8] JvmtiRawMonitor::raw_wait(long, Thread*)+0x64 V [libjvm.dylib+0xac51d8] JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, long)+0x64 C [libbi04t002.dylib+0x9cb4] syncDebuggeeStatus(JNIEnv_*, _jvmtiEnv*, int)+0x47c C [libbi04t002.dylib+0x9800] Java_nsk_share_jvmti_DebugeeClass_checkStatus+0x64 j nsk.share.jvmti.DebugeeClass.checkStatus(I)I+0 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.runIt([Ljava/lang/String;Ljava/io/PrintStream;)I+40 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.run([Ljava/lang/String;Ljava/io/PrintStream;)I+9 j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.main([Ljava/lang/String;)V+9 v ~StubRoutines::call_stub V [libjvm.dylib+0x800fec] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc V [libjvm.dylib+0xdf2fe8] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, JavaThread*)+0x10bc V [libjvm.dylib+0xdf1dd8] Reflection::invoke_method(oop, Handle, objArrayHandle, JavaThread*)+0x2cc V [libjvm.dylib+0x94d620] JVM_InvokeMethod+0x44c j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@17-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+133 java.base@17-internal j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base@17-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base@17-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base@17-internal v ~StubRoutines::call_stub
21-06-2021
Did you try adding the assert that you mentioned in the previous comment?
18-06-2021
I would have loved to be able to reproduce it to test the proposed fix, but I ran the test continuously in a loop on my mac mini over night and nothing. Still, I will do the fix and run it via Mach5...
18-06-2021
The fix for JDK-8265182 was basically: void ProgrammableInvoker::invoke_native(Stub stub, address buff, JavaThread* thread) { - MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread)); ThreadToNativeFromVM ttnfvm(thread); + MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread)); Here it looks like we need: int JvmtiRawMonitor::simple_wait(Thread* self, jlong millis) { guarantee(_owner == self , "invariant"); guarantee(_recursions == 0, "invariant"); QNode node(self); enqueue_waiter(node); simple_exit(self); guarantee(_owner != self, "invariant"); int ret = M_OK; if (self->is_Java_thread()) { JavaThread* jt = self->as_Java_thread(); guarantee(jt->thread_state() == _thread_in_native, "invariant"); { // This transition must be after we exited the monitor. ThreadInVMfromNative tivmfn(jt); if (jt->is_interrupted(true)) { ret = M_INTERRUPTED; } else { + MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, thread)); ThreadBlockInVM tbivm(jt); if (millis <= 0) { self->_ParkEvent->park(); } else { self->_ParkEvent->park(millis); } // Return to VM before post-check of interrupt state }
18-06-2021
I can't help to think that if we did what I suggested here https://github.com/openjdk/jdk/pull/3920#pullrequestreview-660085698 then we would have caught this case and asserted nicely.
18-06-2021
There seems to be some XML magic in src/hotspot/share/prims/jvmtiEnter.xsl and jvmti.xml that controls which JVMTI function use ThreadInVMfromNative/ThreadWXEnable based on the "innative" flag, which means the wrapper sets up the real function to run in InVM mode. Other functions, like raw monitor enter/exit/wait run in Native mode and switch to InVM mode themselves, so they need a corresponding ThreadWXEnable.
17-06-2021
JvmtiRawMonitor code like simple_wait, raw_enter, and raw_wait use ThreadInVMfromNative without ThreadWXEnable. Shouldn't ThreadWXEnable be part of ThreadInVMfromNative?
17-06-2021
Hmm, this really looks like JDK-8265182 https://github.com/openjdk/jdk/pull/3921 I'd love to be able to reproduce it locally.
17-06-2021
It's still failing in our testing according to reports: --------------- T H R E A D --------------- Current thread (0x0000000137019820): JavaThread "MainThread" [_thread_in_vm, id=42767, stack(0x000000016f494000,0x000000016f697000)] Stack: [0x000000016f494000,0x000000016f697000], sp=0x000000016f694fe0, free space=2051k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xeb1a24] MarkActivationClosure::do_code_blob(CodeBlob*)+0x74 V [libjvm.dylib+0xf0d0a4] JavaThread::nmethods_do(CodeBlobClosure*)+0xe0 V [libjvm.dylib+0x736868] HandshakeOperation::do_handshake(JavaThread*)+0x70 V [libjvm.dylib+0x7383a0] HandshakeState::process_self_inner()+0x2a4 V [libjvm.dylib+0x738010] HandshakeState::process_by_self()+0x134 V [libjvm.dylib+0xdcd604] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x54 V [libjvm.dylib+0x2a179c] ThreadBlockInVMPreprocess<InFlightMutexRelease>::~ThreadBlockInVMPreprocess()+0x138 V [libjvm.dylib+0xaa3104] JvmtiRawMonitor::simple_wait(Thread*, long)+0x220 V [libjvm.dylib+0xaa3468] JvmtiRawMonitor::raw_wait(long, Thread*)+0x50 V [libjvm.dylib+0xa7b948] JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, long)+0x64 C [libbi04t002.dylib+0x977c] syncDebuggeeStatus(JNIEnv_*, _jvmtiEnv*, int)+0x574 C [libbi04t002.dylib+0x91d0] Java_nsk_share_jvmti_DebugeeClass_checkStatus+0x64 J 2675 nsk.share.jvmti.DebugeeClass.checkStatus(I)I (0 bytes) @ 0x0000000110d6bf84 [0x0000000110d6bec0+0x00000000000000c4] C 0x0000000117db7b98 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 2675 nsk.share.jvmti.DebugeeClass.checkStatus(I)I (0 bytes) @ 0x0000000110d6bf84 [0x0000000110d6bec0+0x00000000000000c4] j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.runIt([Ljava/lang/String;Ljava/io/PrintStream;)I+40 J 2577 c2 nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.run([Ljava/lang/String;Ljava/io/PrintStream;)I (13 bytes) @ 0x0000000110cf0524 [0x0000000110cf0480+0x00000000000000a4] j nsk.jvmti.scenarios.bcinstr.BI04.bi04t002.main([Ljava/lang/String;)V+9 v ~StubRoutines::call_stub J 2573 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-ea (0 bytes) @ 0x0000000110cf1b70 [0x0000000110cf1ac0+0x00000000000000b0] J 2572 c2 jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-ea (137 bytes) @ 0x0000000110d0fce4 [0x0000000110d0fc00+0x00000000000000e4] J 2571 c2 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-ea (10 bytes) @ 0x0000000110d0f8a4 [0x0000000110d0f840+0x0000000000000064] J 2547 c2 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@17-ea (65 bytes) @ 0x0000000110cffd00 [0x0000000110cffc80+0x0000000000000080] j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 J 2536 c2 java.lang.Thread.run()V java.base@17-ea (17 bytes) @ 0x0000000110cf5ca8 [0x0000000110cf5c40+0x0000000000000068] v ~StubRoutines::call_stub siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr: 0x0000000110d6be78
17-06-2021
Tried to reproduce locally with: jtreg -nr -va -nativepath:/Volumes/Work/tmp/jdk/build/macosx-aarch64-server-release/support/test/hotspot/jtreg/native/lib/ -jdk:./build/macosx-aarch64-server-release/images/jdk/ -vmoption:-XX:+TieredCompilation test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/TestDescription.java without success. It could because, like Mikhailo noticed, it looks like JDK-8265182 or JDK-8265292, which are fixed. Can probably be closed with "Can not reproduce".
16-06-2021
ILW = HLM = P3
18-05-2021
Crash is similar to JDK-8265182, JDK-8265292. It seems likely to be another W^X issue. Runtime, please take a look.
12-05-2021