JDK-8294160 introduced changes for getting more information for a crash dump. The changes were then backported to 17.0.7 in JDK-8301335.

Among other things, the change included the following addition in Method::is_valid_method:

  } else if (!os::is_readable_range(m, m + 1)) {
    return false;

os::is_readable_range() is implemented with SafeFetch32.
Before JDK-8283326, SafeFetch was generated dynamically in the Code Cache area. On Apple M1/M2 architecture the memory for the dynamic code generation can be either writable or executable, but not both at the same time (W^X).

AsyncGetCallTrace, widely used for profiling (by means of async-profiler), also calls Method::is_valid_method(). Since a thread calling AsyncGetCallTrace is not guaranteed to be in "executable" JIT state, it's illegal to call dynamically generated SafeFetch.

JDK 17.0.7 started crashing on Mac M1 during profiling:

# SIGBUS (0xa) at pc=0x000000013fd394e4, pid=80473, tid=120091

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::SafeFetch32
V [libjvm.dylib+0x7aea40] _ZN2os17is_readable_rangeEPKvS1_+0x2c
V [libjvm.dylib+0x75d0c8] _ZN6Method15is_valid_methodEPKS_+0x38
V [libjvm.dylib+0x34d1d0] _ZL31forte_fill_call_trace_given_topP10JavaThreadP15ASGCT_CallTracei5frame+0x460
V [libjvm.dylib+0x34cd48] AsyncGetCallTrace+0x1e0

Note: the bug applies only to 17.0.7. It's not an issue with JDK 20+ since SafeFetch was made static in JDK-8283326.