Roland Westrelin roland.westrelin at
Mon May 14 04:30:42 PDT 2012


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 if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) {

would fix the problem on 64 bit as well.

Should I make this change?


More information about the hotspot-compiler-dev mailing list