JDK-6898462 : The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,7,8,8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2009-11-05
  • Updated: 2024-01-30
  • Resolved: 2014-12-08
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.
JDK 8 JDK 9
8u40Fixed 9 b44Fixed
Related Reports
Duplicate :  
JDK-8020533 - JVM crashed with assert(!value->obj_is_scalar_replaced()) failed: object should be reallocated already
Relates :  
JDK-8067144 - SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects
Relates :  
JDK-8066400 - Reserve memory for OOME exception processing during deoptimization
Relates :  
JDK-8270010 - Handling of failed reallocation of scalar-replaced objects skips some exception handlers
Relates :  
JDK-8324174 - assert(m->is_entered(current)) failed: invariant
Relates :  
JDK-8146416 - java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized
Description
See example in attachment. I tested it on my solaris-i586 for JDK7b74.

Here is run string:
/net/vmsqe.russia/export/jdk/re/7/promoted/ea/b74/binaries/solaris-i586/fastdebug/bin/java  -server -Xmixed -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -Xmx8M -XX:+DoEscapeAnalysis -cp /export/home/lm153972/NetBeansProjects/Tests/build/classes tests.Main

Here is the result for product:
should not reach here
final
Exception in thread "main" java.lang.NullPointerException
	at tests.Main.eatMemory(Main.java:40)
	at tests.Main.main(Main.java:71)


Here is the result (for fastdebug):
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/vframeArray.cpp:94
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/BUILD_AREA/jdk7/hotspot/src/share/vm/runtime/vframeArray.cpp:94), pid=2482, tid=2
#  Error: assert(!value->obj_is_scalar_replaced(),"object should be reallocated already")
#
# JRE version: 7.0-b74
# Java VM: Java HotSpot(TM) Server VM (17.0-b03-fastdebug mixed mode solaris-x86 )
# An error report file with more information is saved as:
# /export/home/lm153972/NetBeansProjects/testbase/vm/ant-build/hs_err_pid2482.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...
Abort (core dumped)

These tests fails due this issue (they are not excluded from tun):

nsk/monitoring/stress/classload/unload001
nsk/monitoring/stress/classload/unload002
nsk/monitoring/stress/classload/unload003
nsk/monitoring/stress/classload/unload004
nsk/monitoring/stress/classload/unload005
nsk/monitoring/stress/classload/unload006
nsk/monitoring/stress/classload/unload007
nsk/monitoring/stress/classload/unload008
nsk/monitoring/stress/classload/unload009
nsk/monitoring/stress/classload/unload010
nsk/monitoring/stress/classload/unload011
nsk/monitoring/stress/classload/unload012
Also these:-

gc/gctests/LargeObjects/large001/large001
gc/gctests/LargeObjects/large003
gc/gctests/LargeObjects/large004
gc/gctests/LargeObjects/large005
Also fails

gc/gctests/Steal/steal001
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4d5b47a5184d User: lana Date: 2014-12-23 22:27:38 +0000
23-12-2014
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4d5b47a5184d User: roland Date: 2014-12-08 11:37:42 +0000
08-12-2014
Comment from John (from JDK-8061801): The JVM must not crash. The root cause of this bug is an OOM condition. So throw an OOM, which will not crash the JVM. That will allow the user to observe the problem and try to continue. There is a potential problem in that the OOM may appear to come from a line of code that does not have a visible construct that can throw OOM. But that is a relatively minor problem, since lines of Java code can have implicit conversions (boxing) that might throw OOM.
07-11-2014
RULE gc/lock/jni/jnilock001 Crash Internal Error ...vframeArray.cpp..... RULE gc/lock/jni/jnilock003 Crash Internal Error ...vframeArray.cpp.....
12-04-2013
EVALUATION During deoptimization caused by OutOfMemoryError exception VM can't reallocate a scalar replaced object but it continue the execution with assumtion that the object was reallocated.
07-11-2009