Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8055530

assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined

    Details

    • Subcomponent:
    • Resolved In Build:
      b47

      Backports

        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)

          Activity

          Hide
          neliasso Nils Eliasson added a comment -
          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
          Show
          neliasso Nils Eliasson added a comment - 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
          Hide
          neliasso Nils Eliasson added a comment -
          Now happend in our nightly -> P1
          Show
          neliasso Nils Eliasson added a comment - Now happend in our nightly -> P1
          Hide
          twisti Christian Thalinger added a comment -
          [~neliasso], are there hs_err and core files somewhere?
          Show
          twisti Christian Thalinger added a comment - [~neliasso], are there hs_err and core files somewhere?
          Hide
          mdoerr Martin Doerr added a comment -
          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.
          Show
          mdoerr Martin Doerr added a comment - 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.
          Hide
          roland Roland Westrelin added a comment -
          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.
          Show
          roland Roland Westrelin added a comment - 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.
          Hide
          roland Roland Westrelin added a comment -
          Regarding lack of test case: needs concurrent class loading and compilation. Hard to get in a simple test case.
          Show
          roland Roland Westrelin added a comment - Regarding lack of test case: needs concurrent class loading and compilation. Hard to get in a simple test case.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7dfa629d203a
          User: roland
          Date: 2015-01-05 21:52:49 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/7dfa629d203a User: roland Date: 2015-01-05 21:52:49 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7dfa629d203a
          User: lana
          Date: 2015-01-21 21:54:46 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7dfa629d203a User: lana Date: 2015-01-21 21:54:46 +0000

            People

            • Assignee:
              roland Roland Westrelin
              Reporter:
              rbackman Rickard Backman
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: