Test nsk/stress/except/except001 fails with 5.0u10 b01-b03 but passes with 5.0u9 FCS. It fails only with -agentlib:JVMTIagent option, without it it passes. See steps to reproduce the bug in comments field.
Comments
EVALUATION
I have applied to 1.5u10 ws the Swamy's fix from the bug:
6200349 VMObjAlloc rpts non-java objects (Was:linux-amd64:
JVMTI library crashes HotSpot in libc_free+0x21)
With that fix the problem has gone.
So, this bug is another appearence of the 6200349 and, probably, has to be closed
as a dup of 6200349. I'll check if there is any plan to backport 6200349 to 1.5u.
27-01-2007
EVALUATION
Nicolay, thank you for the test and for the analysis you have done!
You pointed to the exact behavior, so I'm finally convinced that it is a bug in JVMTI.
I used your new test to track down this issue.
First, I completely proved (at least to myself) that it is not a regression in 5u10.
This new test shows that 5u9 has the same failure mode as 5u10 for mostly all VM modes,
including: -d64/-server/-client and Xmixed/Xcomp/Xint.
It also shows that all 1.5 releases have the same bug.
Moreover, it is interesting that this problem was represented in JDK 6 before b68.
But it has been fixed in b68.
My current guess is that it was done by the Swamy's fix for the bug:
6200349 VMObjAlloc rpts non-java objects (Was:linux-amd64:
JVMTI library crashes HotSpot in libc_free+0x21)
It looks like the fix for 6200349 was not backported to 1.5 update yet.
I'm going to check if Swamy's fix helps to resolve this issue.
If so, I'll close this bug (6495021) as a dup of the 6200349, otherwise
some additional analysis is needed.
24-01-2007
EVALUATION
I was able to reproduce this failure with 5.0u1, 5.0u8 and even 5.0u9 (32-bit sparc).
The flag -server is needed to reproduce it on 5.0u9, but it is usually passed with -client.
However, I found that the 5.0u9 Client VM is failed on Solaris-x86 with -Xint.
But the corresponding debug (java_g) VM is passed with -Xint.
Therefore, it looks like it just depends on memory layout and so, not a regression.
I think that using the flag -agentlib:JVMTIagent just triggers a memory layout change.
Another question to answer is whether it is a bug in the VM or in the test.
I think I've found the source of this behavior and so, can explain what really happens.
The java_g with the flag -XX:+TraceExceptions was used to get tracing info.
The most confusing thing was that OOM was thrown several times in different places:
- several original OOMs provoked and caught in the method raiseOutOfMemory
- OOM rethrown by the method raiseOutOfMemory itself
- OOM which is thrown when the VM reflection code wraps the OOM into
InvocationTargetException but has not enough memory to construct
new exception object
- other OOMs which can be thrown before the VM reflection code is completed
To avoid this confusion and make things clear I've modified the original test (see the comment).
Now the test method raiseOutOfMemory throws java.lang.Error instead of OOM.
This is the most relevant fragment from the output showing what happend:
----------------------------------------------------------------------
Exception <a 'java/lang/Error'> (0xb3f6a400) thrown in compiled method <{method} 'raiseOutOfMemory' '()V' in 'nsk/stress/except/except001/except001'> at PC 0xb9d02052 for thread 0x8090270
Thread 0x08090270 continuing at PC 0x00000000 for exception thrown at PC 0xb9d02052
Exception <a 'java/lang/OutOfMemoryError'> (0xb5a69338 )
thrown [/BUILD_AREA/jdk1.5.0_10/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp, line 84]
for thread 0x08090270
Exception <a 'java/lang/OutOfMemoryError'> (0xb5a69338 )
thrown [/BUILD_AREA/jdk1.5.0_10/hotspot/src/share/vm/runtime/reflection.cpp, line 919]
for thread 0x08090270
...
----------------------------------------------------------------------------
It is clear from the output above that the VM fails to wrap the java.lang.Error
into an InvocationTargetException because it hits another OOM when creates an exception object.
In this case, I don't know what the VM could do in order to satisfy the test requirements which looks to strong to me. This test not simply eats Java heap memory a lot but eats in a such a way that there is no even small pieces left in the Java heap.
The original intention of the test developper was to provoke a VM crash.
In this case, the VM does not crash but just returns OOM.
It looks as a resonable behavior to me especially after reading the spec below.
Class OutOfMemoryError is an indirect subclass of the java.lang.Error.
This is what the spec says:
(A) "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions."
(B) "An OutOfMemoryError is thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector."
So, I still think the test has to expect an OOM to be thrown as well.
Also, it would be nice to make similar changes as I did and throw some different Exception of Error
instead of OOM in the test method raiseOutOfMemory.
I move this bug to the hotspot/test subcategory again.
If there is still any doubt that it is right then, probably, we would need to ask some of the VM experts to make a final conclusion.
Nicolay, thank you for helping with the analysis anyway!
22-11-2006
EVALUATION
I have added the following catch clause into except001.run() method:
} catch (OutOfMemoryError oome) {
System.out.println("ss45998: OOM has caught in except001.run() !");
return 0;
}
and the test was passed with the jdk 5.0u10 on Solaris-i586:
sh except001.tlog
# While printing this message, JVM seems to initiate the output
# stream, so that it will not need more memory to print later,
# when the heap would fail to provide more memory.
#
# That problem is caused by the known JDK/HotSpot bugs:
# 4239841 (P1/S5) 1.1: poor garbage collector performance
# 4245060 (P4/S5) poor garbage collector performance
#
# This message is just intended to work-around that problem.
# If printing should fail even so.
ss45998: OOM has caught in except001.run() !
So, I move this bug to the hotspot/test category.
22-11-2006
EVALUATION
I was able to reproduce this failure on Solaris-i586 and Solaris-sparc with both
5.0u10 and 5.0u11. This failure is not reproducible on the same platforms with 5.0u9.
However, the same failure mode with 5.0u9 is reproducible on Solaris-sparcv9 machine lapwai.sfbay (see below).
So, I think, it is not a regression. So, I'm changing the priority to p3.
Most likely the "regression" keyword needs to be deleted.
Mioreover, I think, it can be a test bug.
The test allocate a lot of small objects to eat all the memory on the heap.
It does it in hope to provoke a VM crash.
In such a case, it has to handle OOM exception when it occurs.
In fact, the test program does it in one place when allocates memory.
But it has to expect an OOM exception in other places as well.
For reference, please, see similar test bugs:
6206134: TEST_BUG: nsk/share/ClassUnloader.unloadClass() should catch OutOfMemoryError
6405798: nsk.share.ClassUnloader.eatMemory() can throw unexpected OutOfMemoryError
This bug looks very similar to the bug 4239841 closed by Peter K. in 1.3 as "Not a bug".
It would be better if someone of the GC experts look at it.
ss45998@lapwai cat /home/ss45998/tt/nsk_bug/hs_mm.Nov21.sparc/ss45998.Solaris.sparc/except001/except001.tlog
#!/bin/sh
CLASSPATH=/home/ss45998/tt/nsk_bug/hs_mm.Nov21.sparc/ss45998.Solaris.sparc/except001:/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/bin/classes:/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/lib/tools.jar
PATH=/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/bin:/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/src/nsk/share/classes:/bin
HOME=/home/ss45998
LD_LIBRARY_PATH=/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/src/nsk/share/lib/sparcv9:/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/jre/lib/sparcv9/server
RAS_OPTIONS=
DISPLAY=bratsk:1.0
SHELL=/bin/sh
while [ $# -gt 0 ];
do
if [ $1 = "-jdk" ]; then
shift 1
PATH=${1}/bin:${PATH}
shift 1
else
if [ $1 = "-d" ]; then
shift 1
if [ $# -gt 0 ]; then
DISPLAY=$1
shift 1
else
DISPLAY=:0.0
fi
fi
fi
done
export CLASSPATH
export PATH
export HOME
export LD_LIBRARY_PATH
export RAS_OPTIONS
export DISPLAY
export SHELL
/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/bin/javac -d /home/ss45998/tt/nsk_bug/hs_mm.Nov21.sparc/ss45998.Solaris.sparc/except001/ /home/ss45998/tt/nsk_bug/hs_mm.Nov21.sparc/ss45998.Solaris.sparc/except001/*.java
##Exit status of Java compilation=0
CLASSPATH=/home/ss45998/tt/nsk_bug/hs_mm.Nov21.sparc/ss45998.Solaris.sparc/except001:/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/bin/classes:/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/lib/tools.jar
PATH=/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/bin:/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/src/nsk/share/classes:/bin
HOME=/home/ss45998
LD_LIBRARY_PATH=/net/vice.russia/export/home0/dtf/dtf_ws/suites/1.5.0_URv09/vm2/testbase_SCA_5.0-build-v15r33.Aug_01_2006/vm/src/nsk/share/lib/sparcv9:/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/jre/lib/sparcv9/server
RAS_OPTIONS=
DISPLAY=bratsk:1.0
SHELL=/bin/sh
while [ $# -gt 0 ];
do
if [ $1 = "-jdk" ]; then
shift 1
PATH=${1}/bin:${PATH}
shift 1
else
if [ $1 = "-d" ]; then
shift 1
if [ $# -gt 0 ]; then
DISPLAY=$1
shift 1
else
DISPLAY=:0.0
fi
fi
fi
done
export CLASSPATH
export PATH
export HOME
export LD_LIBRARY_PATH
export RAS_OPTIONS
export DISPLAY
export SHELL
#annotate TEST javaopt=-d64 -server -agentlib:JVMTIagent
/java/re/jdk/1.5.0_09/promoted/latest/binaries/solaris-sparcv9/bin/java -d64 -server -agentlib:JVMTIagent except001
##Exit status of execution step=1
##!checkExitCode
## While printing this message, JVM seems to initiate the output
## stream, so that it will not need more memory to print later,
## when the heap would fail to provide more memory.
##
## That problem is caused by the known JDK/HotSpot bugs:
## 4239841 (P1/S5) 1.1: poor garbage collector performance
## 4245060 (P4/S5) poor garbage collector performance
##
## This message is just intended to work-around that problem.
## If printing should fail even so.
#Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
ss45998@lapwai