SIGBUS or SIGSEGV on OSX?
Bob Vandette
bob.vandette at oracle.com
Mon May 14 05:54:03 PDT 2012
I had to fix the same problem in the signal handler for iOS. I had
problems with implicit null checks and safepoint polling exceptions
when running our JDK7 Embedded build on iPads and iPhones.
Make sure you check all cases of SIGSEGV.
Bob.
-----Original Message-----
From: Roland Westrelin
Sent: Monday, May 14, 2012 7:31 AM
To: hotspot-runtime-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net
Cc: hotspot compiler
Subject: SIGBUS or SIGSEGV on OSX?
Hi,
We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method:
siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018
The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000.
The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash.
I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this:
#if defined(__APPLE__) && !defined(AMD64)
// 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions.
// Catching SIGBUS here prevents the implicit SIGBUS NULL check below from
// being called, so only do so if the implicit NULL check is not necessary.
} else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else
} else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif
would fix the problem on 64 bit as well.
Should I make this change?
Roland.
More information about the hotspot-compiler-dev
mailing list