RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField

David Holmes david.holmes at oracle.com
Tue Apr 13 04:46:23 UTC 2021


Hi Anton,

On 10/04/2021 4:32 am, Anton Kozlov wrote:
> Hi, please review a fix for a random crash on macos/aarch64.
> 
> By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug:
> 
> v  ~BufferBlob::jni_fast_GetLongField
> V  [libjvm.dylib+0x7a6538]  Perf_Detach+0x168

I'm struggling to see how we get to the jni_fast_GetLongField from 
Perf_Detach ??

> j  jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal
> j  jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal
> j  jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal
> j  jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal
> j  jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal
> j  java.lang.Thread.run()V+11 java.base at 17-internal
> j  jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal
> v  ~StubRoutines::call_stub
> 
> One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases.
> 
> This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode.

Once again I'm finding it very hard to understand what the actual rules 
are for these W^X mode changes and what code requires what. IIUC the 
normal(?) mode is WXExec and we use that when executing JITed or other 
native code. But if we enter the VM we need to switch to WXWrite mode. 
So that is what the PERF_ENTRY (via JVM_ENTRY) does for Perf_Detach. But 
for some reason these generated fast-accessors need to be run in WXExec 
mode. So IIUC the transitions that are already in place for executing 
"VM code" are going to be wrong any time that VM code ends up executing 
something like a fast-accessor - is that the case? And what other code 
is in the same category as these generated fast-accessors?

Thanks,
David


> -------------
> 
> Commit messages:
>   - Add W^X in FastGetXXXField
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3422/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3422&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8262896
>    Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/3422.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/3422/head:pull/3422
> 
> PR: https://git.openjdk.java.net/jdk/pull/3422
> 


More information about the hotspot-dev mailing list