Crash when JRE 17.0.7 is used

[lujiajing1126]

When using JRE 17.0.7 on MacOS (Apple Silicon), crashes happen.

/Users/megrez/.local/share/zinit/plugins/asdf-vm---asdf/.asdf/installs/java/temurin-17.0.7+7/bin/java -javaagent:/Users/megrez/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/231.8770.65/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=57687:/Users/megrez/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/231.8770.65/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -classpath /Users/megrez/Code/playground/async-profiler-demo/target/classes:/Users/megrez/.m2/repository/tools/profiler/async-profiler/2.9/async-profiler-2.9.jar org.example.profiler.App
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x00000001156114e4, pid=79343, tid=10243
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.7+7 (17.0.7+7) (build 17.0.7+7)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (17.0.7+7, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# v  ~StubRoutines::SafeFetch32
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/megrez/Code/playground/async-profiler-demo/hs_err_pid79343.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

Tested with several JDK distributions,

• Temurin 17.0.7
• Zulu 17.42.19 (17.0.7)
• Corretto-17.0.7.7.1

But the issue can only be reproducible on Apple Silicon platform (aarch64). Degrading JDK to 17.0.6 or using x86_64 (Intel models) work well.

Attached you may find the detailed report,

Current thread (0x000000012f00ce00):  JavaThread "main" [_thread_in_Java, id=10243, stack(0x000000016b8c0000,0x000000016bac3000)]

Stack: [0x000000016b8c0000,0x000000016bac3000],  sp=0x000000016bac1720,  free space=2053k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v  ~StubRoutines::SafeFetch32
V  [libjvm.dylib+0x7c7460]  os::is_readable_range(void const*, void const*)+0x2c
V  [libjvm.dylib+0x77426c]  Method::is_valid_method(Method const*)+0x38
V  [libjvm.dylib+0x361558]  frame::is_interpreted_frame_valid(JavaThread*) const+0x7c
V  [libjvm.dylib+0x35e584]  forte_fill_call_trace_given_top(JavaThread*, ASGCT_CallTrace*, int, frame)+0x3b4
V  [libjvm.dylib+0x35e1a8]  AsyncGetCallTrace+0x1e0
C  [libasyncProfiler-8960398290752333206.so+0x20dc0]  Profiler::getJavaTraceAsync(void*, ASGCT_CallFrame*, int, StackContext*)+0x15c
C  [libasyncProfiler-8960398290752333206.so+0x21cf8]  Profiler::recordSample(void*, unsigned long long, int, Event*)+0x1c4
C  [libasyncProfiler-8960398290752333206.so+0x2df9c]  WallClock::signalHandler(int, __siginfo*, void*)+0xb0
C  [libsystem_platform.dylib+0x3a84]  _sigtramp+0x38
C  0xb454000115615fc8
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x470c70]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x38c
V  [libjvm.dylib+0x4d5e40]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)+0x12c
V  [libjvm.dylib+0x4d946c]  jni_CallStaticVoidMethod+0x130
C  [libjli.dylib+0x54ac]  JavaMain+0x9d4
C  [libjli.dylib+0x77f4]  ThreadJavaMain+0xc
C  [libsystem_pthread.dylib+0x6fa8]  _pthread_start+0x94

hs_err_pid79343.log

[lujiajing1126]

Just find your ticket in the community https://bugs.openjdk.org/browse/JDK-8307549

[apangin]

Right, that's exactly the JVM bug I reported recently.
It happens only on JDK 17.0.7 with Apple M1/M2 hardware.

[lujiajing1126]

Right, that's exactly the JVM bug I reported recently. It happens only on JDK 17.0.7 with Apple M1/M2 hardware.

Is that possible that the JDK community accepts the patch for this bug in 17 LTS soon? As you said, the impl of SafeFetch32 has changed in JDK 20+.

[snazarkin]

@apangin should not the protection switch be moved after call of _asyncGetCallTrace?

[apangin]

@snazarkin It's on the right place. This was added to workaround the JVM bug when AsyncGetCallTrace updated pc_desc_cache in the executable memory area.

Note that AsyncGetCallTrace may be called at any arbitrary point when a thread WX state is unknown/undefined, so AsyncGetCallTrace should neither attempt to write nor execute the code in the CodeCache.

[apangin]

Added a temporary workaround in macos-crash branch until the bug is fixed in OpenJDK.

[apangin]

The workaround has been implemented in async-profiler.
Also, the bug is fixed in JDK 17.0.9.