United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6845368 large objects cause a crash or unexpected exception
JDK-6845368 : large objects cause a crash or unexpected exception

Details
Type:
Bug
Submit Date:
2009-05-27
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
windows_vista,linux,generic
Sub-Component:
gc
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs17,6u13,6u14
Fixed Versions:
hs17 (b01)

Related Reports
Backport:
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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
TestObject100K@55f33675
Test Passed

[pattern 2]: specifying -XX:+UseSerialGC
> java -XX:+UseSerialGC MainTest_021_02
TestObject100K@26ee7a14
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
#
abort

[pattern 2]: specifying -XX:+UseSerialGC
> java -XX:+UseSerialGC MainTest_021_02
java.lang.NullPointerException
        at MainTest_021_02.main(MainTest_021_02.java:49)
The name of failed tests for tracking purposes:
gc/gctests/LargeObjects/large003
gc/gctests/LargeObjects/large004
gc/gctests/LargeObjects/large005

                                    

Comments
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.
                                     
2009-05-28
SUGGESTED FIX

Use unsigned int instead of unsigned short (u2 or jushort) to hold oop offsets in ClassFileParser and OopMapBlock.
                                     
2009-06-02
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.
                                     
2009-06-02
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/9eebd3ac74cf
                                     
2009-08-25
SUGGESTED FIX

See attached patch (6845368.patch); the test case is large.
                                     
2009-08-25
EVALUATION

http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e13afc88afa5
                                     
2009-09-03
EVALUATION

http://hg.openjdk.java.net/hsx/hsx16/master/rev/e13afc88afa5
                                     
2009-09-04
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eebd3ac74cf
                                     
2009-09-25



Hardware and Software, Engineered to Work Together