KONNO Kazuhiro

`x10` has the `currentThread->sp` value, and the code in `old_slow_jitHandleInternalErrorTrap()` tries to store 0 to the address `x10 - 40` (= InaccessibleAddress 0x104FFFFF8). ``` 650a74: str xzr, [x10, #-40]! ```...

No memory is allocated at 0x104FFFFF8. There is a memory block of 8MB starting from 0x105000000. ``` > info mmap 0x105000020 Start Address End Address Size Size Read/Write/Execute 0x0000000105000000 0x00000001057fffff...

https://github.com/eclipse-openj9/openj9/issues/15352#issuecomment-1190403943 shows a similar failure with Symbol=old_slow_jitHandleInternalErrorTrap from a different testcase.

Running the "!stack" command against "JIT Compilation Thread-000" shows the following error: ``` > !threads !stack 0x10d863900 !j9vmthread 0x10d863900 !j9thread 0x12d012850 tid 0x109ae6f (17411695) // (main) !stack 0x10d878700 !j9vmthread 0x10d878700...

> InaccessibleAddress=0000000114FFFFF8 It tried to access an address where no memory is mapped. Same as before. I see the following output for one of the JIT Compilation Threads with jdmpview:...

I need ideas on how to debug this -- What is happening in the JIT compilation thread upon crash? Native stack trace is unavailable on AArch64 macOS.

That does not work as expected, unfortunately. I get the following output by running `thread backtrace all` in lldb with the core file. ``` (lldb) thread backtrace all * thread...

I ran a 30x Grinder job with the -Xrs option, but it failed to reproduce the failure. internal job/Grinder/27171/

Another Grinder job didn't crash, either. job/Grinder/27189/

I should have looked at the javacore file earlier. ``` 1XMCURTHDINFO Current thread 3XMTHREADINFO "JIT Compilation Thread-003" J9VMThread:0x0000000143823B00, omrthread_t:0x000000013201C460, java/lang/Thread:0x000000028021D518, state:R, prio=10 3XMJAVALTHREAD (java/lang/Thread getId:0x6, isDaemon:true) 3XMJAVALTHRCCL jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000002802251B8) 3XMTHREADINFO1 (native...