United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7167254 Crash on OSX in Enumerator.nextElement() with compressed oops
7167254 : Crash on OSX in Enumerator.nextElement() with compressed oops

Details
Type:
Bug
Submit Date:
2012-05-08
Status:
Resolved
Updated Date:
2013-04-30
Project Name:
JDK
Resolved Date:
2012-05-26
Component:
hotspot
OS:
os_x
Sub-Component:
compiler
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs21,7,7u6
Fixed Versions:
hs24

Related Reports
Backport:
JDK-2224792 - Crash on OSX in Enumerator.nextElement() with compressed oops
Backport:
JDK-2225106 - Crash on OSX in Enumerator.nextElement() with compressed oops
Backport:
JDK-2225057 - Crash on OSX in Enumerator.nextElement() with compressed oops
Backport:
JDK-8002519 - Crash on OSX in Enumerator.nextElement() with compressed oops
Backport:
JDK-8002520 - Crash on OSX in Enumerator.nextElement() with compressed oops
Duplicate:
JDK-7129716 - MAC: SIGBUS in sun.util.PreHashedMap.get with compiler/6865031/Test.java
Duplicate:
JDK-7167497 - Crash on OSX in ResolverConstraint.getSelectedSupplier
Duplicate:
JDK-7171800 - Random crashes when running Eclipse without -Xmx set

Sub Tasks

Description
For complete set of crashes and full dump see: http://phonehome.se.oracle.com/phonehome-web/index.jsp?show=group&id=6099


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x0000000108099530, pid=60769, tid=140735190452576
#
# JRE version: 7.0_04-b17
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b18 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# J  java.util.Hashtable$Enumerator.nextElement()Ljava/lang/Object;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007f8f1a040000):  JavaThread "main" [_thread_in_Java, id=1997064544, stack(0x00007fff64944000,0x00007fff65144000)]

siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x000000010de4f018

Comments
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4073d9478a90
2012-06-29 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4073d9478a90
2012-05-18 
EVALUATION

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.
2012-05-14


Hardware and Software, Engineered to Work Together