JDK-8055530 : assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-08-20
  • Updated: 2023-07-21
  • Resolved: 2015-01-05
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
8u102Fixed 9 b47Fixed
Description
Test failed in nightlies: 

;; Using jvm: "/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/comp_baseline/linux-i586/jre/lib/i386/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/192921.vkozlov/s/src/share/vm/opto/parse1.cpp:989), pid=18485, tid=3843935088
#  assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b26) (build 1.9.0-ea-fastdebug-b26)
# Java VM: Java HotSpot(TM) Server VM (1.9.0-fastdebug-internal-201408151929.vkozlov.main_to_comp compiled mode linux-x86 )
# Core dump written. Default location: /export/local/aurora/sandbox/results/client/9/core or core.18485
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0xe559c800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=18505, stack(0xe515c000,0xe51dd000)]

Stack: [0xe515c000,0xe51dd000],  sp=0xe51dafa0,  free space=507k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1066c08]  VMError::report_and_die()+0x198;;  VMError::report_and_die()+0x198
V  [libjvm.so+0x6dc8d6]  report_vm_error(char const*, int, char const*, char const*)+0x76;;  report_vm_error(char const*, int, char const*, char const*)+0x76
V  [libjvm.so+0xde6ee7]  Parse::do_exits()+0xad7;;  Parse::do_exits()+0xad7
V  [libjvm.so+0xdf0d98]  Parse::Parse(JVMState*, ciMethod*, float)+0xdd8;;  Parse::Parse(JVMState*, ciMethod*, float)+0xdd8
V  [libjvm.so+0x513a28]  ParseGenerator::generate(JVMState*)+0x158;;  ParseGenerator::generate(JVMState*)+0x158
V  [libjvm.so+0x653dc2]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1362;;  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1362
V  [libjvm.so+0x5123b7]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x327;;  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x327
V  [libjvm.so+0x661d59]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x629;;  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x629
V  [libjvm.so+0x6637b0]  CompileBroker::compiler_thread_loop()+0x550;;  CompileBroker::compiler_thread_loop()+0x550
V  [libjvm.so+0xfc43f5]  compiler_thread_entry(JavaThread*, Thread*)+0x55;;  compiler_thread_entry(JavaThread*, Thread*)+0x55
V  [libjvm.so+0xfd85d9]  JavaThread::thread_main_inner()+0x299;;  JavaThread::thread_main_inner()+0x299
V  [libjvm.so+0xfd89e6]  JavaThread::run()+0x296;;  JavaThread::run()+0x296
V  [libjvm.so+0xd99810]  java_start(Thread*)+0x100;;  java_start(Thread*)+0x100
C  [libpthread.so.0+0x6a49]
C  [libc.so.6+0xdee1e]  clone+0x5e


Current CompileTask:
C2:  32761 5460    b        sun.nio.cs.ISO_8859_1::newEncoder (10 bytes)
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7dfa629d203a User: lana Date: 2015-01-21 21:54:46 +0000
21-01-2015
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7dfa629d203a User: roland Date: 2015-01-05 21:52:49 +0000
05-01-2015
Regarding lack of test case: needs concurrent class loading and compilation. Hard to get in a simple test case.
05-01-2015
I couldn't reproduce the crash either running the tests for a couple of days or using the replay files. From a core file: - method being compiled is sun.nio.cs.ISO_8859_1::newDecoder public java.nio.charset.CharsetDecoder newDecoder(); Code: 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder 3: dup 4: aload_0 5: aconst_null 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."<init>":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V 9: areturn _exits.control() is a Region node. _gvn.type(ret_phi) is top ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result above the center line, which filter turns into top.
18-12-2014
No clue what the cause of the assertion is in this bug, but we know that the assertion can be obtained by doing the following: 1. define a static final field 2. define a method which just returns the field 3. use setAccessible(true) (reflection), makes the field non-final 4. use set (reflection) to change the type of the field to an incompatible type 5. compile the method with C2 while the type gets changed We know that doing this is illegal, but it is interesting that we can make C2 run into the assertion or generate wrong code. C2 tries to meet the type of the current oop with the type which it got from the constant pool. This results in type "Top" which can't be used to generate the return value leading to this assertion or wrong code in product build.
01-12-2014
[~neliasso], are there hs_err and core files somewhere?
20-11-2014
Now happend in our nightly -> P1
20-11-2014
This is an old bug, but was closed on 7u60 because we never could reproduce it. ILW=Assert, Low, None=MLH=P4, add one for bigapps, -> P3
02-09-2014