When a crash occurs because execution transferred to a PC of 0 (e.g., null vtable entry, corrupt/incomplete JNI function table), the hs-err log does not contain a native stack trace, making it much harder to diagnose what happened.

Instead, error handling could speculate that the previous instruction was a call in which case the return address has been pushed to the stack (x86) or written to the link register (ARM). It can then investigate the return value to see if the preceding instruction at that address is indeed a call instruction. If so, it should be reasonable to attempt a native stack walk from there.