JDK-8233032 : assert(in_bb(n)) failed: must be
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-10-25
  • Updated: 2022-06-27
  • Resolved: 2019-12-10
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 13 JDK 14
11.0.7-oracleFixed 13.0.3Fixed 14 b27Fixed
Related Reports
Relates :  
Description
Attached test crashes with 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/opto/superword.hpp:358), pid=15949, tid=15960
#  assert(in_bb(n)) failed: must be
#
# JRE version: Java(TM) SE Runtime Environment (14.0+20) (fastdebug build 14-ea+20-879)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+20-879, compiled mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x165ef71]  SuperWord::bb_idx(Node*)+0x41
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /tmp/fuzzer.tmp.K4CDlMZW6b/core.15949)
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test Test

Host:, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 4 cores, 14G, Oracle Linux Server release 7.5
Time: Fri Oct 25 09:08:38 2019 UTC elapsed time: 0 seconds (0d 0h 0m 0s)

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

Current thread (0x00007f7e54257800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=15960, stack(0x00007f7e2aff5000,0x00007f7e2b0f6000)]


Current CompileTask:
C2:    237   10    b  4       Test::mainTest (579 bytes)

Stack: [0x00007f7e2aff5000,0x00007f7e2b0f6000],  sp=0x00007f7e2b0f0200,  free space=1004k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x165ef71]  SuperWord::bb_idx(Node*)+0x41
V  [libjvm.so+0x164f0ef]  SuperWord::independent(Node*, Node*)+0x1f
V  [libjvm.so+0x1650119]  SuperWord::co_locate_pack(Node_List*)+0xef9
V  [libjvm.so+0x16503fd]  SuperWord::schedule()+0x2d
V  [libjvm.so+0x165e42a]  SuperWord::SLP_extract()+0x22a
V  [libjvm.so+0x165e950]  SuperWord::transform_loop(IdealLoopTree*, bool)+0x220
V  [libjvm.so+0x1200105]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1155
V  [libjvm.so+0x9d63da]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x2ea
V  [libjvm.so+0x9d366c]  Compile::Optimize()+0xadc
V  [libjvm.so+0x9d4c34]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1094
V  [libjvm.so+0x81b760]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x110
V  [libjvm.so+0x9e104c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2cc
V  [libjvm.so+0x9e1ff8]  CompileBroker::compiler_thread_loop()+0x468
V  [libjvm.so+0x16ece36]  JavaThread::thread_main_inner()+0x226
V  [libjvm.so+0x16f2626]  Thread::call_run()+0xf6
V  [libjvm.so+0x14150ae]  thread_native_entry(Thread*)+0x10e


Comments
Fix Request (13u) This fixes the C2 crash. Patch applies cleanly to 13u. New test fails without the product fix, and passes with it.
25-03-2020

Fix Request (11u) This fixes the C2 crash, and keeps codebases in sync (I see 11.0.7-oracle). Patch applies cleanly to 11u. New test fails without the product fix, and passes with it. Additionally, it passes tier1 and tier2 tests. Risk is medium, as it affects loop opts.
16-01-2020

http://cr.openjdk.java.net/~chagedorn/8233032/webrev.00/ The problem of the bug can be traced back to finding the first and last memory state of a load when processing a load pack in SuperWord::co_locate_pack() [1]. One load of a load pack in the test case is dependent on the store node 's' which is sandwiched between other store nodes 'p1' and 'p2' of a store pack (p1 -> s -> p2). The other load of the load pack is dependent on the store node 'p2'. The sandwiched store node 's' swaps positions with 'p2' to move it out of the pack dependencies: p1 -> p2 -> s. However, the bb indices are not updated (bb_idx(s) < bb_idx(p2) is still true). Therefore, it sets last_mem to the memory state of the first load in the loop at [1]. As a result, the graph walk at [2] always starts following the input of the memory state of the first load (which should actually be the one of the last load) and will move beyond a loop phi as the stop condition is never met for a node having another memory state than the first one of the load pack. Eventually a bb index for a node outside of the loop is read resulting in the seen assertion failure. The fix is to look up the first and last memory state without using bb indices as it probably is quite difficult to update them properly when moving sandwiched stores around. This patch adopts Roland's original solution [3][4] which was then replaced by a version using bb indices (causing this bug). [1] https://hg.openjdk.java.net/jdk/jdk/file/5defda391e18/src/hotspot/share/opto/superword.cpp#l2258 [2] https://hg.openjdk.java.net/jdk/jdk/file/5defda391e18/src/hotspot/share/opto/superword.cpp#l2276 [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-April/028702.html [4] http://cr.openjdk.java.net/~roland/8201367/webrev.00/
10-12-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/3b693618d084 User: thartmann Date: 2019-12-10 08:30:43 +0000
10-12-2019

Could reproduce locally by using -XX:UseAVX=1 Reproduces with JDK 11 but not with 8.
27-11-2019

[~lmesnik] Hi Leonid, could you also attach the failing test, please?
21-11-2019

Might be related to JDK-8229694.
29-10-2019

ILW = Assert in superword optimization, reproducible with JavaFuzzer generated test, disable superword = HMM = P2
29-10-2019