JDK-8229855 : C2 fails with assert(false) failed: bad AD file
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u231,9,10,11,12,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-08-18
  • Updated: 2022-06-27
  • Resolved: 2020-01-13
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 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 14 b32Fixed 15Fixed
Related Reports
Relates :  
JDK-8237055 - [TESTBUG] compiler/c2/TestJumpTable.java fails with release VMs
Relates :  
JDK-8238812 - assert(false) failed: bad AD file
Relates :  
JDK-8236721 - C2 should better optimize not-equal integer comparisons
Relates :  
JDK-8200303 - C2 should leverage profiling for lookupswitch/tableswitch
Description
(synopsis is provisional, please change as you see fit)

Found by fuzzing. Crashes every time with the generated test. Test bundle is attached, it also includes hs_errs.

$ java Test
Default case invoked for: 
   opcode  = 102, "Con"
o1      Con     === o0  [[]]  #top

--N: o1 Con     === o0  [[]]  #top

#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/opto/matcher.cpp:1588), pid=26509, tid=26566
#  assert(false) failed: bad AD file
#
# JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.shade.jdk-jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x12c50dd]  Matcher::Label_Root(Node const*, State*, Node*, Node const*)+0x51d

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

Current thread (0x00007f21bc009000):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26566, stack(0x00007f21eda02000,0x00007f21edb03000)]

Current CompileTask:
C2:    749   76   !   4       Test::vMeth (1622 bytes)

Stack: [0x00007f21eda02000,0x00007f21edb03000],  sp=0x00007f21edafdac0,  free space=1006k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12c50dd]  Matcher::Label_Root(Node const*, State*, Node*, Node const*)+0x51d
V  [libjvm.so+0x12c5005]  Matcher::Label_Root(Node const*, State*, Node*, Node const*)+0x445
V  [libjvm.so+0x12c5445]  Matcher::match_tree(Node const*)+0x1e5
V  [libjvm.so+0x12c85ea]  Matcher::xform(Node*, int)+0x9ba
V  [libjvm.so+0x12cb917]  Matcher::match()+0xb07
V  [libjvm.so+0x9c0c15]  Compile::Code_Gen()+0x85
V  [libjvm.so+0x9c5294]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1244
V  [libjvm.so+0x8004cd]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x10d
V  [libjvm.so+0x9d1767]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x397
V  [libjvm.so+0x9d28d8]  CompileBroker::compiler_thread_loop()+0x4f8
V  [libjvm.so+0x182ce1a]  JavaThread::thread_main_inner()+0x26a
V  [libjvm.so+0x1834a08]  JavaThread::run()+0x238
V  [libjvm.so+0x1832456]  Thread::call_run()+0xf6
V  [libjvm.so+0x143045e]  thread_native_entry(Thread*)+0x10e
Comments
Seems like it introduced/exposed regressions: JDK-8238812.
19-08-2020
Fix Request (13u) The reasons are the same as for 11u. Was not able to reproduce on aarch64, but x86 is definitely affected. Applies cleanly, pass tier1
28-05-2020
Fix Request (11u) This fixes the C2 crash (miscompilation?) and keeps codebases in sync (I see 11.0.8-oracle). Patch applies cleanly to 11u, new test fails without the patch, passes with it. Patched JDK also passes tier{1,2,3} tests.
29-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk14/rev/d50867368bac User: thartmann Date: 2020-01-13 12:37:21 +0000
13-01-2020
http://cr.openjdk.java.net/~thartmann/8229855/webrev.00/ For the switch statement in TestJumpTable.java, C2 creates the following binary search tree with a jump table at (*): if (key_val > 45) { if (key_val != 60) { if (key_val <= 60) { (*) } else { [...] } } else { [...] } } else { [...] } The jump table at (*) handles the following key_val ranges: {46..50}, {51}, {52..59}. Parse::jump_switch_ranges -> Parse::create_jump_tables adds a CastII to narrow the type of key_val to type int:46..59 (type int:0..13 after normalizing to zero): http://hg.openjdk.java.net/jdk/jdk/file/44cb1f517839/src/hotspot/share/opto/parse2.cpp#l884 Now after some rounds of loop unrolling, key_val is known to be int:60..260 (normalized to int:14..214) in one of the loop bodies. As a result, the narrow CastII node is replaced by TOP and we crash in the matcher because the JumpNode user didn't go away. The problem is that the key_val != 60 && key_val <= 60 combination is *not* found to be always false if key_val becomes known as int:60..260 because C2's type system does not narrow the type after the first check. The fix is to simply strengthen the second check to ensure that both control and data paths die consistently. I would like to push this simple fix into JDK 14 and follow-up in JDK 15 with an enhancement that adds a general optimization for such integer checks (see JDK-8236721).
07-01-2020
I've attached a simple test that reproduces this even with -XX:-UseSwitchProfiling: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::test -Xbatch Test
22-11-2019
The problem is that the range check dependent CastII emitted by Parse::create_jump_tables -> C->conv_I2X_index becomes TOP: (rr) print key_val->dump(2) 1634 CastII === 1554 1632 [[ 1635 ]] #int:0..106:www range check dependency !jvms: Test::vMeth @ bci:81 114 ConI === 0 [[ 116 274 745 1637 ]] #int:3 1635 ConvI2L === _ 1634 [[ 1636 1637 ]] #long:0..106:www !jvms: Test::vMeth @ bci:81 1637 LShiftL === _ 1635 114 [[]] !jvms: Test::vMeth @ bci:81 Later: 1632 AddI === _ 677 1633 [[ 1634 ]] !jvms: Test::vMeth @ bci:81 1554 IfTrue === 1553 [[ 1638 1634 ]] #1 !jvms: Test::vMeth @ bci:81 1634 CastII === 1554 1632 [[ 1635 ]] #top range check dependency !jvms: Test::vMeth @ bci:81
22-11-2019
(For now removing 8 from 'Affects Version/s', as the failure is not reproducible with versions prior to 11) This reported issue seems started with, triggered by following fix changeset in jdk-11+11. > https://bugs.openjdk.java.net/browse/JDK-8200303 > http://hg.openjdk.java.net/jdk/jdk/rev/d84f06a0cae1 changeset: 49877:d84f06a0cae1 user: roland date: Tue Apr 24 15:07:20 2018 -0700 summary: 8200303: C2 should leverage profiling for lookupswitch/tableswitch Confirmed -XX:-UseSwitchProfiling usage is workaround for this failure. Also found this issue has less likelihood as the failure happens only with debug builds and no similar failures with product builds. So for now re-triaging this as a P3 issue. (ILW = HLM = P3)
21-08-2019
The reported crash here for the testcase seems started from jdk-11+11 build version onwards. (Got the failure with JDK 11, 12, 13, 14 builds. But got NO failures with latest JDK 8u, 9, 10 build versions) Will work to find the related/triggered fix changeset.
20-08-2019
ILW = Crash during C2 compilation due to unmatchable IR, reproducible with fuzzer test, disable compilation of method = HMM = P2
19-08-2019