JDK-8214862 : assert(proj != __null) at compile.cpp:3251
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u201,8u192,9,10,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-05
  • Updated: 2020-11-30
  • Resolved: 2019-01-09
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 11 JDK 12 JDK 13 JDK 8 Other
11.0.8-oracleFixed 12 b27Fixed 13Fixed 8u281Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
#  Internal Error (/home/roland/hs/src/hotspot/share/opto/compile.cpp:3251), pid=14408, tid=14421
#  assert(proj != __null) failed: must be found


The crash occurs in final_graph_reshape in the following code:

  case Op_Proj: {
    if (OptimizeStringConcat) {
      ProjNode* p = n->as_Proj();
      if (p->_is_io_use) {
        // Separate projections were used for the exception path which
        // are normally removed by a late inline.  If it wasn't inlined
        // then they will hang around and should just be replaced with
        // the original one.
        Node* proj = NULL;
        // Replace with just one
        for (SimpleDUIterator i(p->in(0)); i.has_next(); i.next()) {
          Node *use = i.get();
          if (use->is_Proj() && p != use && use->as_Proj()->_con == p->_con) {
            proj = use;
            break;
          }
        }
        assert(proj != NULL, "must be found");
        p->subsume_by(proj, this);
      }
    }
    break;
  }

because a call only has control/memory/io uses for the exception path
but none for the fall through path. This happens because after the call,
the fallthrough path leads to an infinite loop and that infinite loop
and the path that leads to it is removed. The infinite loop is removed
because there are 2 passes of PhaseRemoveUseless that are executed. One
as part of Compile::inline_string_calls(), and another one right after,
both at the end of parsing:

    if (_late_inlines.length() == 0 && !has_mh_late_inlines() && !failing() && has_stringbuilder()) {
      inline_string_calls(true);
    }

    if (failing())  return;

    print_method(PHASE_BEFORE_REMOVEUSELESS, 3);

    // Remove clutter produced by parsing.
    if (!failing()) {
      ResourceMark rm;
      PhaseRemoveUseless pru(initial_gvn(), &for_igvn);
    }

During parsing, safepoint nodes in infinite loops are kept live with an
extra precedence edge from the Root node to the safepoint. That edge is
removed as part of PhaseRemoveUseless. So the first pass of
PhaseRemoveUseless disconnects the safepoint node in the infinite loop,
the second finds the safepoint node has no uses and removes it.
Comments
Regarding 8u backport request: it looks like there's a regression from this fix (see JDK-8247502 for details). EDIT: wrong alarm, it turned out the bugs are unrelated (see JDK-8247502 for details).
09-07-2020

8u Fix Request Backporting this patch fixes a crash in C2. Patch does not apply cleanly to 8u and requires backporting JDK-8146612 and some adjustments. 8u RFR: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011382.html
02-04-2020

11u Fix Request Backporting this patch fixes a crash in C2. Patch does not apply cleanly to 11u and requires some adjustments. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002670.html
06-03-2020

Hi Rahul. Test case is included as part of the RFR that is out now: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-December/031708.html I haven't verified if the test case fails with older versions but I suspect the underlying bug exists. I will update affected versions.
06-12-2018

pre ILW = possible JVM crash; rare; disable compilation! = HLM = P3 Hi [~roland], Please attach related reproducible test case, hs_err log files etc. if any. Also so can we add older versions also in 'Affects Version/s'? Thanks
06-12-2018

Caused by multiple PhaseRemoveUseless. Likely goes back to JDK-6892658 and made worse by late inlining.
05-12-2018