JDK-4403928 : JVM crashes with an unexpected exception message, when out of memory
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.3.0,1.3.0_01,1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Other
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-01-11
  • Updated: 2012-10-03
  • Resolved: 2012-10-03
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.
Other Other
1.3.1 rc1Resolved 1.4.0Resolved
Related Reports
Relates :  
JDK-4317486 - [sol/c1/b04] assert generation.cpp 469 during scavenge.
Description
Sample java code from ISV crashes the VM. It should throw
an "Out of memory" exception, and exit gracefully. This is
the behaviour seen under JDK 1.2.2_05a. This happens
only when -Xincgc is specified, and crashes with both
-server and -client options.

sample output
-------------

ime since start (ms) : 10941 Delay (in ms)  = 90
[GC 58590K->58873K(59456K), 0.0149205 secs]
[GC 59381K->59705K(60288K), 0.0149067 secs]
[GC 60213K->60537K(61120K), 0.0152537 secs]
[GC 61045K->61369K(61952K), 0.0153932 secs]
[GC 61877K->62201K(62784K), 0.0158629 secs]
[GC 62709K->63033K(63616K), 0.0157312 secs]
[Full GC 63541K->62005K(63616K), 0.0569591 secs]
Time since start (ms) : 11941 Delay (in ms)  = 150
[Full GC 65162K->62522K(62848K), 0.4960092 secs]
Time since start (ms) : 13109 Delay (in ms)  = 507
[GC# # An unexpected exception has been detected in native code outside the VM.# Program counter=0xff270c1c
#
# Problematic Thread: prio=5 tid=0xca3e0 nid=0x4 runnable 
#
Abort (core dumped

To recreate the problem run with the following options:
~/downloads/products/j2re1_3_0/bin/java -server -Xincgc -verbosegc -DMemtest.greadyRR=true Memtest
Comments
Been in resolved state for more than ten years. Closing.
03-10-2012
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird FIXED IN: ladybird INTEGRATED IN: ladybird-rc1 merlin-beta
14-06-2004
EVALUATION jon.masamitsu@Eng 2001-01-24 This bug is not occurring with the latest merlin-beta. $JAVA_HOME/bin/java -server -version java version "1.4.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b48) Java HotSpot(TM) Server VM (build 1.4beta-B48, mixed mode) jane.loizeaux@East 2001-01-31: The train doesn't report failures in expanding the heap, which other generation types do (see bug 4317486). Specifically, oopDesc::copy_to_survivor_space assumes that an object being copied can be copied somewhere (in this case, to a car in the train -- but we couldn't create a car to accomodate the object).
11-06-2004
WORK AROUND Sample application runs with fine when the default heap with -Xmx128 option.
11-06-2004
SUGGESTED FIX ------- generation.cpp ------- 1161c1161,1162 < return NULL; --- > // Do better than this for Merlin > vm_exit_out_of_memory(expand_blocks * CarSpace::car_size(), "heap expansion"); For Merlin, we'll see if an OutOfMemory exception can be thrown. That might be impossible, as the heap might be in an inconsistent state.
11-06-2004
PUBLIC COMMENTS This is a train GC bug.
10-06-2004