JDK-6309516 : OutOfMemoryError test silently exits with code 1 on linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-11
  • Updated: 2012-02-01
  • Resolved: 2006-02-17
Related Reports
Relates :  
JDK-6294934 - Memory allocation produce unhandled OOM
Relates :  
JDK-6362318 - (thread) uncaught exception handler can be silenced by OutOfMemoryError
Description
Attached program causes java to exit with exit code 1 after 15-25 iterations without any messages on linux.

The program does eatMemory() in a loop. eatMemory() tries to fill available memory by allocating chunks of memory till it encounters OOM, then chunk size is halved and is repeated till chunk size is small, then references are released.

I cannot reproduce this on Solaris sparc or x86. The problem only exists with -XX:+UseParallelGC. Options -XX:-UseGCTimeLimit or -XX:ParallelGCThreads seem to have no effect. There is no problem with 1.5.

Steps to reproduce:

javac MemoryEater.java
$JAVA_HOME/bin/java -client -XX:+UseParallelGC -Xmx128M  MemoryEater 5; echo $?
Comments
EVALUATION I can reproduce this with c1 fastdebug builds of 1.6.0 b57 and b58, but not with b59 and later builds (tried b59, b60, b70 and b72). Believe the problem was fixed in b59 as a side effect of the new register allocator for c1 and associated code. The PRT archive for the relevant putback is /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20051022115706.never.merge It includes fixes for the following bug ids: 6320351: new register allocator for c1 4627997: JDI testcase crexreq001 failing with -client -Xcomp only, all platforms 6311902: VM with a new c1 crashes in infinite recursion 6180872: Add methodDataOop profiling to client compiler
17-02-2006
EVALUATION Reproduced the failure running MemoryEater (not MemoryEater1) with 1.6.0-b58 fastdebug client vm (SerialGC) on fastlane.sfbay. A run with -XX:+TraceExceptions shows the program exiting soon after the compiled version of eatMemory() is executed around iteration 20. Suspect the compiled code is not properly handlng the catch or finally block in eatMemory(). Using a more recent fastdebug VM in the same jdk does not fail, so this may have been fixed already.
07-02-2006
EVALUATION The MemoryEater1.java program does not print a message because of changes in the java launcher made in 1.5. The uncaught exception handling code was moved completely into java and can be thwarted by OutOfMemoryError. In 1.4.2 and earlier, at least part of it was done in native (C) code, so at least a partial message was printed. The problem is not due to GC, so bug 6362318 was opened to track this issue. So far I have not been able to reproduce a failure using MemoryEater.java on fastlane.sfbay (Linux fastlane 2.4.21-9.ELsmp #1 SMP Thu Jan 8 17:08:56 EST 2004 i686 i686 i386 GNU/Linux). Will try other machines.
13-12-2005