United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6302804 Hotspot VM dies ungraceful death when C heap is exhausted in various places.
JDK-6302804 : Hotspot VM dies ungraceful death when C heap is exhausted in various places.

Details
Type:
Bug
Submit Date:
2005-07-27
Status:
Closed
Updated Date:
2013-09-12
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
open_solaris,linux_redhat_4.0,linux,generic,solaris_10,solaris_nevada,windows_xp,windows
Sub-Component:
runtime
CPU:
x86,sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
osol_2009.06,solaris_11,hs19,5.0u13,6,6u2,6u5,6u10,6u11,6u23,7
Fixed Versions:
hs20 (b06)

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

Sub Tasks

Description
JDK        	    : Mustang b44
Platform[s]         : Fails On:  winXP Prof.
Failing Test [s]    : CTE_REGTEST/Generic/4765019/ThreadTest.java

    Test source location:
    =====================
/net/jdk/export/jpse04/Regression/1.6.0/test/CTE_REGTEST/Generic/4765019/ThreadTest.java

    jtr file location:
    ==================
/net/cady/export6/results/mustang/b44/reg/regression-cte-reg-XPpro-2005-07-25-10-50-09-0981/workDir/CTE_REGTEST/Generic/4765019/ThreadTest.jtr

    How to reproduce:
    ====================
    - Set JAVA_HOME to Mustang b44 windows-i586
    - cd /net/jdk/export/jpse04/Regression/1.6.0/test/CTE_REGTEST/Generic/4765019     
    - /net/koori.sfbay/onestop/jct-tools/2.1.6/archive/fcs/binaries/win32/bin/jtreg -r:/tmp -w:/tmp ThreadTest.java

    Test output:
    =============
----------System.out:(14/486)----------
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
7104
7105
7106
7107
7108
7109
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:587)
        at ThreadTest.main(ThreadTest.java:17)
Unrecognized VM option '+UseDefaultStackSize'
Unrecognized VM option '+UseDefaultStackSize'
Could not create the Java virtual machine.
----------System.err:(46/1418)*----------
java full version "1.6.0-ea-b44"
+ grep Unrecognized VM option test.out 
+ [ 1 != 0 ] 
+ + wc -l test.out 
+ awk {print $1} 
L_NO=7114 
+ grep OutOfMemoryError test.out 
+ [ 0 = 0 ] 
+ + grep -n OutOfMemoryError test.out 
+ cut -f1 -d : 
L_NO=7111 
+ + expr 7111 - 1 
L_NO=7110 
+ + head -7110 test.out 
+ tail -1 
VAL=7109 
+ tail test.out 
+ VAL1=7109 
+ [ 7109 = 0 ] 
+ Execute_Command -Xss256K -XX:+UseDefaultStackSize 0 22616 
+ cd Y:/dtf/unified/knight-ws/exec/regression-cte-reg-XPpro-2005-07-25-10-50-09-0981/results/workDir/scratch 
+ VAL=0 
+ rm -f test.out 
+ C:/jdk/b44/windows-i586/jdk1.6.0\\bin\\java -Xss256K -XX:+UseDefaultStackSize ThreadTest 
+ sleep 10 
+ [ 0 = 0 ] 
+ + ps 
+ grep ThreadTest 
+ grep -v grep 
+ awk {print $1} 
C_PID= 
+ sleep 120 
+ kill -s 9 
kill: Execute_Command 3: Y:\\dtf\\unified\\knight-ws\\suites\\regression\\cte-test\\CTE_REGTEST\\Generic\\4765019\\Test4765019.sh 128: Usage: kill -l [status]
        kill [-s SIGNAL] job ...
+ chmod 777 ThreadTest.class test.out 
+ set -x 
+ grep Unrecognized VM option test.out 
+ [ 0 != 0 ] 
+ tail test.out 
+ VAL3=0 
+ + echo 7109 
+ awk {AA = $1; BB = AA * 0.9; print BB} 
VAL4=6398.1 
+ [ 0 -ge 7109 -o 0 -ge 6398.1 ] 
[: Y:\\dtf\\unified\\knight-ws\\suites\\regression\\cte-test\\CTE_REGTEST\\Generic\\4765019\\Test4765019.sh 141: unknown operator in arithmetic expression "6398.1" near 8.
result: Failed. Execution failed: exit code 1
The hs_err* file is incomplete because it gets an error while printing out all of the threads, but if I comment out that part of vmError.cpp, I can get a stack trace:



Stack: [0xf5da0000,0xf5de0000),  sp=0xf5ddeb0c,  free space=250k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8f9c47] void VMError::report_and_die()+0x597
V  [libjvm.so+0x38cbee] void report_vm_out_of_memory(const char*,int,unsigned,const char*)+0xae
V  [libjvm.so+0x1ee067] void*Chunk::operator new(unsigned,unsigned)+0xf7
V  [libjvm.so+0x1ee90f] void*Arena::grow(unsigned)+0x4f
V  [libjvm.so+0x1ef9ef] void*Arena::Amalloc(unsigned)+0xbf
V  [libjvm.so+0x330aef] Node_Stack::Node_Stack(int)+0x7f
V  [libjvm.so+0x6bdbd4] MStack::MStack(int)+0x34
V  [libjvm.so+0x6baa06] void Matcher::find_shared(Node*)+0x56
V  [libjvm.so+0x6b61a5] void Matcher::match()+0x705
V  [libjvm.so+0x32d255] void Compile::Code_Gen()+0xc5
V  [libjvm.so+0x32990c] Compile::Compile(ciEnv*,C2Compiler*,ciMethod*,int,bool)+0xd1c
V  [libjvm.so+0x24ffe7] void C2Compiler::compile_method(ciEnv*,ciMethod*,int)+0x77
V  [libjvm.so+0x33860b] void CompileBroker::invoke_compiler_on_method(CompileTask*)+0x3d7
V  [libjvm.so+0x337e2c] void CompileBroker::compiler_thread_loop()+0x3a4
V  [libjvm.so+0x88e046] void compiler_thread_entry(JavaThread*,Thread*)+0x66
V  [libjvm.so+0x8891cc] void JavaThread::thread_main_inner()+0x15c
V  [libjvm.so+0x88905e] void JavaThread::run()+0x11e
V  [libjvm.so+0x732c2e] java_start+0x19e
C  [libc.so.1+0x9f6f8] _thr_setup+0x4e
C  [libc.so.1+0x9f9e0] _lwp_start+0x0


The compiler is still running when the VM runs out of memory, and blows up trying to allocate memory for compilation.

To get this on x86 -server run:  java -mx10m ThreadTest

                                    

Comments
EVALUATION

It's not just the compiler thread.  Any thread that tries to allocate memory in an arena when the created threads have eaten up all of memory, will crash:

Stack: [0xf5de2000,0xf5e32000),  sp=0xf5e30938,  free space=314k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8f9c87] void VMError::report_and_die()+0x597
V  [libjvm.so+0x38cc2e] void report_vm_out_of_memory(const char*,int,unsigned,const char*)+0xae
V  [libjvm.so+0x1efef1] void*ChunkPool::allocate(unsigned)+0x101
V  [libjvm.so+0x1edff1] void*Chunk::operator new(unsigned,unsigned)+0x81
V  [libjvm.so+0x1ee90f] void*Arena::grow(unsigned)+0x4f
V  [libjvm.so+0x1ef9ef] void*Arena::Amalloc(unsigned)+0xbf
V  [libjvm.so+0x7e62e5] char*ResourceArea::allocate_bytes(unsigned)+0xc5
V  [libjvm.so+0x7e5c71] char*resource_allocate_bytes(unsigned)+0x41
V  [libjvm.so+0x45e06b] void*GenericGrowableArray::raw_allocate(int)+0x4b
V  [libjvm.so+0x4ca2f1] GrowableArray<methodOop>::GrowableArray(int,bool)+0x61
V  [libjvm.so+0x6561ec] int klassVtable::get_num_mirandas(klassOop,objArrayOop,objArrayOop)+0x5c
V  [libjvm.so+0x652d2d] void klassVtable::compute_vtable_size_and_num_mirandas(int&,int&,klassOop,objArrayOop,AccessFlags,oop,symbolOop,objArrayOop)+0x2ad

This is a day one problem and is too risky to change the behaviour of the VM for mustang.  OutOfMemoryError is thrown and a message in the assert.  Are there more bugs open that request better oom handling?

# An unexpected error has been detected by Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 32764 bytes for ChunkPool::allocate. Out of swap space?
#
                                     
2005-11-07
EVALUATION

This is really an enhancement to oom handling where the C heap is exhausted and we need more space.  It might be a long time before we fix this.  This is not a customer generated request.
                                     
2007-09-14
EVALUATION

Customers do hit this problem but it won't be fixed in the next release.  There's a fair bit of work to gracefully handle C heap exhaustion in the VM.
                                     
2008-10-29
EVALUATION

Today the vast majority of service calls are due to the fact that the 4g process
size limit for 32 bit has been hit. There is almost never a shortage in RAM/swap.
It might be a good idea to explicitly mention that fact. E.g. by adding a "possible
reasons" section:

# Possible reasons:
#   In 32 bit mode, the 4g process size limit was hit
#   The system was out of physical RAM or swap space
# Possible solutions:
    ....

The message "out of swap space?"  which we get today is a red herring
                                     
2010-12-21
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/36c186bcc085
                                     
2011-01-03
EVALUATION

I changed the error reporting so that out of swap and out of native (C heap) memory doesn't look like a VM assert or look like a java.lang.OutOfMemoryError exception that someone could catch.  The suggested new wording is in the bug link Evaluation section.  I'm open to rewording if people have strong preferences.
Also, if solaris runs out of swap space (generally by filling up /tmp), access to thread stacks generate a bus error with ENOMEM errno.  I can check for this in the solaris signal handler and give the out of C heap message.  I couldn't get Linux or windows to fail the same way, so didn't apply similar changes there.
                                     
2011-01-03
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36c186bcc085
                                     
2011-01-08



Hardware and Software, Engineered to Work Together