JDK-8294217 : Assertion failure: parsing found no loops but there are some
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.16.1,17,20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86_64
  • Submitted: 2022-09-15
  • Updated: 2023-01-04
  • Resolved: 2022-11-14
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 17 JDK 20
17.0.7-oracleFixed 20 b24Fixed
Related Reports
Relates :  
JDK-8257574 - C2: "failed: parsing found no loops but there are some" assert failure
Relates :  
JDK-8297642 - PhaseIdealLoop::only_has_infinite_loops must detect all loops that never lead to termination
Relates :  
JDK-8253923 - C2 doesn't always run loop opts for compilations that include loops
Description
ADDITIONAL SYSTEM INFORMATION :
Arch: x86_64
OS: Ubuntu 20.04

Java: 
- openjdk version "11.0.17-internal" 2022-10-18
- OpenJDK Runtime Environment (fastdebug build 11.0.17-internal+0-adhoc.congli.jdk11u-dev)
- OpenJDK 64-Bit Server VM (fastdebug build 11.0.17-internal+0-adhoc.congli.jdk11u-dev, mixed mode)

Release:
```
IMPLEMENTOR="N/A"
JAVA_VERSION="11.0.17"
JAVA_VERSION_DATE="2022-10-18"
LIBC="gnu"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.ldap jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Linux"
SOURCE=".:git:74daa996b521"
```

Javac: javac 11.0.17-internal


A DESCRIPTION OF THE PROBLEM :
This is a JIT compiler bug triggering an assertion failure in the C2 compiler:

#  Internal Error (/zdata/congli/hotspot-build-env/jdk11u-dev/src/hotspot/share/opto/loopnode.cpp:2925), pid=2522998, tid=2523010
#  assert(_ltree_root->_child == __null || C->has_loops() || only_has_infinite_loops() || C->has_exception_backedge()) failed: parsing found no loops but there are some

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac T.java
2. java -Xmx1G -XX:-BackgroundCompilation -XX:-PrintWarnings --illegal-access=deny T

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
NO crash
ACTUAL -
Crashed

---------- BEGIN SOURCE ----------
import java.net.Socket;

class T {
  long l;

  void q() {
    if (b) {
      Socket s = new Socket();
      return;
    }
    do {
      l++;
      while (l != 1) --l;
      l = 9;
    } while (l != 5);
  }

  public static void main(String[] p) {
    T t = new T();
    for (int i = 524; i < 19710; i += 1) {
      b = true;
      t.q();
      b = false;
    }
    t.q();
  }

  static Boolean b;
}

---------- END SOURCE ----------

FREQUENCY : always
Comments
Fix request [17u] I backport this for parity with 17.0.7-oracle. Typical C2 risk, but we should go along. Two related issues are fixed in 16, the other is only loosly related and will be backported, too. Clean backport. Test passes, but passes also without the fix. SAP nightly testing passed.
04-01-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1024 Date: 2023-01-03 13:44:06 +0000
03-01-2023
Changeset: 8c472e48 Author: Roland Westrelin <roland@openjdk.org> Date: 2022-11-14 15:08:15 +0000 URL: https://git.openjdk.org/jdk/commit/8c472e481676ed0ef475c4989477d5714880c59e
14-11-2022
ILW = Debug assert in C2, single test case and debug VM only, no workaround = MLH = P4
31-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10904 Date: 2022-10-28 14:34:42 +0000
28-10-2022
Reproducible with current jdk with this change: diff --git a/src/hotspot/share/opto/compile.cpp b/src/hotspot/share/opto/compile.cpp index b3c9c9a4784..abe1b071268 100644 --- a/src/hotspot/share/opto/compile.cpp +++ b/src/hotspot/share/opto/compile.cpp @@ -2315,7 +2315,7 @@ void Compile::Optimize() { if (has_loops()) { // Cleanup graph (remove dead nodes). TracePhase tp("idealLoop", &timers[_t_idealLoop]); - PhaseIdealLoop::optimize(igvn, LoopOptsMaxUnroll); + PhaseIdealLoop::optimize(igvn, LoopOptsNone); if (major_progress()) print_method(PHASE_PHASEIDEAL_BEFORE_EA, 2); if (failing()) return; }
26-09-2022
The assertion is introduced in JDK 11.0.12 by a backport of JDK-8253923. JDK-8257574 (also backported into JDK 11.0.12) partially addresses the failure, but does not seem to deal with the exact case reported here. The failure cannot be reproduced in JDK 16 (where JDK-8253923 is originally fixed) or later, passing on to sustaining.
23-09-2022
Issue is reproduced . Crash is observed on fastdebug build. OS: Windows 10 JDK 11.0.16.1 fastdebug: Fail Moving it to dev team for further analysis. ILW = assertion failure in debug build (no failure observed in release build); reported once ; disable compilation of affected method = MLM = P4
22-09-2022