JDK-6588262 : Integer overflow caused GC to throw OutOfMemory error with large heap
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6,6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8,windows_vista
  • CPU: x86
  • Submitted: 2007-08-02
  • Updated: 2010-08-06
  • Resolved: 2010-05-05
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode)


FULL OS VERSION :
Linux 2.6.9-22.20.ELsmp #1 SMP Fri Nov 18 03:04:44 EST 2005 x86_64 x86_64 x86_64 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
Large heap (about 128G in total)

A DESCRIPTION OF THE PROBLEM :
One of our application which utilise a large heap has caused an OutOfMemoryError, and an hotspot error has been generated (attached below).

The problem is due to this code in the GrowableArray:

class GenericGrowableArray : public ResourceObj {
 protected:
  int    _len;          // current length
  int    _max;          // maximum length
  Arena* _arena;        // Indicates where allocation occurs:

Note that _len and _max are ints (32 bit values). The algorithm used for growing the array is to double the previous size. The initial size is 0x28. If you keep doubling this then eventually it will overflow from 0x50000000 to 0xA0000000. In decimal, this is of course -1610612736 which is the value you see in the hotspot file.



THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

EXPECTED VERSUS ACTUAL BEHAVIOR :
It should not throw an out of memory error and crash.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
see attachment



REPRODUCIBILITY :
This bug can be reproduced always.

Comments
EVALUATION In CR 6806226 the integer overflow caused a crash. Such an overflow (depending on the particulars) can attempt a large C heap allocation that will fail as in this CR. Closed as duplicate of 6806226.
05-05-2010

EVALUATION The collectors (and other parts of the VM?) should switch from GrowableArray to a new GrowableStack class that grows and shrinks in modest chunks, and uses size_t's for the size, etc. That will solve a bunch of problems.
02-08-2007