JDK-5095540 : JVM crash with outOfMemoryError in growableArray.cpp error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_05
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-09-01
  • Updated: 2005-09-24
  • Resolved: 2005-09-24
Related Reports
Relates :  
JDK-6806226 - Signed integer overflow in growable array code causes JVM crash
Description
Customer's Java application is silently exiting (crashing) with the following error in the GC logs:

Exception java.lang.OutOfMemoryError: requested 16384000 bytes for GrET*
in
D:/BUILD_AREA/jdk142-update/ws/fcs/hotspot\src\share\vm\utilities\growab
leArray.cpp. Out of swap space?

==

The last few lines of a GC log look like:

310699.430: [ParNew 607490K->545850K(989600K), 0.0159794 secs]
310717.674: [ParNew 607542K->545964K(989600K), 0.0164997 secs]
310750.552: [Full GC 569453K->547638K(989600K), 6.9573254 secs]

===

The JVM flags in use are:

-Xrs -Xmx1570M -XX:+UseParNewGC

The system was found to have sufficient memory/swap at the time of this problem.
Comments
EVALUATION See CR 6806226. A failure with a similar error message can occur when larger heaps are used and an integer overflows occurs in an internal calculation. 6806226 is fixed in jdk 6 update 14.
01-07-2009
EVALUATION This bug has been in incomplete state for a year now, I haven't got any further information about the problem, how to reproduce it, etc. That said, as far as I can tell from the bug report and JDC comments, the system has run out of either physical memory or virtual memory. (it's also possible, like suggested in one JDC comment, that there still is some space left in virtual memory, but it's so fragmented that it can't accommodate the malloc request from VM). It doesn't appear to be a bug in the VM. JVM internal data structures are allocated in C heap, which is separate from Java heap and managed by C library. Because Java heap and C heap (and several other things) share and compete for the same physical and virtual space, by reducing Java heap usage (-Xmx/-Xms) an application might be able to get around this issue because now JVM could have more space for its own data. The bug has raised several issues. Some of them (e.g. 4965918, ShowMessageBoxOnError after running out memory) have been addressed in mustang. Some of them are part of a much bigger problem (e.g. automatic recovery after fatal error/OOM) that there is no good solution yet. I'm closing the bug as not reproducible. If you have more information and believe there is a problem in the VM, please reopen with detailed information.
24-09-2005
WORK AROUND none
22-09-2004
EVALUATION Post tiger work ###@###.### 2004-09-02
02-09-2004