JDK-6845368 : large objects cause a crash or unexpected exception
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs17,6u13,6u14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,windows_vista
  • CPU: x86
  • Submitted: 2009-05-27
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
The attached test program showed a crash down or exception thrown on jdk6u4 but the problem could not be seen n in jdk6u3.

Below are the results reported by one of our licensees.

- The problem occurs against jdk 7(b59) on Linux/x86(64bit).
- The problem occurs against jdk 6u13 on Linux/x86(32bit).
- The problem does Not occurs against jdk 6u11, 6u14 on Windows/x86(32bit).
- The problem will disappear if the number of fields in class TestObject100K_021B is decreased(remove all private long fields).
- When -XX:+UseSerialGC is specified, there are some references pointing Eden region that should point Survivor or Tenured space. We suspect wrong operation exists in pointer update when copying objects.

To reproduce:
(1)unzip the attached.
(2)javac *.java
(3)java MainTest_021_02

Test results:

On jdk 6u3:
[pattern 1]: no flags specified
> java MainTest_021_02
Test Passed

[pattern 2]: specifying -XX:+UseSerialGC
> java -XX:+UseSerialGC MainTest_021_02
Test Passed

On jdk 6u13: proglem occurred
> java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

[pattern 1]: no flags specified
> java MainTest_021_02
# An unexpected error has been detected by Java Runtime Environment:
#  SIGSEGV (0xb) at pc=0x0000002a95c14587, pid=18243, tid=1076017504
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.3-b02 mixed mode linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x589587]
# An error report file with more information is saved as:
# /home/okada/for_sun/hs_err_pid18243.log
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

[pattern 2]: specifying -XX:+UseSerialGC
> java -XX:+UseSerialGC MainTest_021_02
        at MainTest_021_02.main(MainTest_021_02.java:49)
The name of failed tests for tracking purposes:

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eebd3ac74cf

EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/e13afc88afa5

EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e13afc88afa5

SUGGESTED FIX See attached patch (6845368.patch); the test case is large.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9eebd3ac74cf

SUGGESTED FIX Use unsigned int instead of unsigned short (u2 or jushort) to hold oop offsets in ClassFileParser and OopMapBlock.

EVALUATION Both ClassFileParser and OopMapBlock (in instanceKlass.hpp) use an unsigned short to hold the offset (in bytes) of the start of a block of oops within an object. This overflows with large objects. This is a long-standing bug that was made somewhat more prevalent by the fix for 6523674 Allow different styles of java object fields allocation which moved oop fields to the end of an object by default. The test case in the attachment for_sun.tgz.zip passes if the option -XX:FieldsAllocationStyle=0 is used on the command line to cause oop fields to be placed at the beginning of the object. However, it's straightforward to come up with a test case that fails even with -XX:FieldsAllocationStyle=0.

EVALUATION The problem is readily reproducible with recent jdk7 builds. The following command line eliminates all GCs, which allows the test to pass: java -Xmx2g -XX:NewSize=1500m -XX:+PrintGCDetails MainTest_021_02 This command line, however, results in a single scavenge and the test fails with an NPE: java -Xmx2g -XX:NewSize=800m -XX:+PrintGCDetails MainTest_021_02 The failure is independent of the GC type; it fails with UseParallelGC, UseParNewGC and UseSerialGC.