JDK-8284635 : Crashes after 8282221: assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows
  • CPU: x86_64
  • Submitted: 2022-04-11
  • Updated: 2022-04-15
  • Resolved: 2022-04-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 19
19 masterFixed
Related Reports
Duplicate :  
JDK-8284663 - [C2] assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
Relates :  
JDK-8282221 - x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long
Relates :  
JDK-8262256 - C2 intrinsincs should not modify IR when bailing out
Sub Tasks
JDK-8284689 :  
ProblemList java/lang/Integer/Unsigned.java in -Xcomp mode - Resolved
Description
Test: java/lang/Integer/Unsigned.java

Flags: '-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation'


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14723/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/dc999d20-0b9e-45a0-a56e-a0a5d62ec11b/runs/0465d409-f0a1-4a56-ab74-7df41d85d328/workspace/open/src/hotspot/share/opto/library_call.cpp:140), pid=15469, tid=15487
#  assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
#
# JRE version: Java(TM) SE Runtime Environment (19.0+18) (fastdebug build 19-ea+18-1175)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-ea+18-1175, compiled mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x133e4c4]  LibraryIntrinsic::generate(JVMState*)+0x284
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14421/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b35e1d04-72f8-4b37-acef-d679dcc5f979/runs/3040b9d8-2706-4b1c-a9c1-1b150fbd785c/testoutput/test-support/jtreg_open_test_jdk_jdk_lang/scratch/4/core.15469)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

Command Line: -Xmx768m -XX:MaxRAMPercentage=4.16667 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14421/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b35e1d04-72f8-4b37-acef-d679dcc5f979/runs/3040b9d8-2706-4b1c-a9c1-1b150fbd785c/testoutput/test-support/jtreg_open_test_jdk_jdk_lang/tmp -ea -esa -Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+TieredCompilation -Djava.library.path=/opt/mach5/mesos/work_dir/jib-master/install/jdk-19+18-1175/linux-x64-debug.test/jdk/jtreg/native --patch-module=java.base=/opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14421/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b35e1d04-72f8-4b37-acef-d679dcc5f979/runs/3040b9d8-2706-4b1c-a9c1-1b150fbd785c/testoutput/test-support/jtreg_open_test_jdk_jdk_lang/patches/java.base -Djava.security.policy=file:/opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14421/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b35e1d04-72f8-4b37-acef-d679dcc5f979/runs/3040b9d8-2706-4b1c-a9c1-1b150fbd785c/./testoutput/test-support/jtreg_open_test_jdk_jdk_lang/jtreg.policy com.sun.javatest.regtest.agent.AgentServer -id 47 -logfile /opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S14421/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b35e1d04-72f8-4b37-acef-d679dcc5f979/runs/3040b9d8-2706-4b1c-a9c1-1b150fbd785c/testoutput/test-support/jtreg_open_test_jdk_jdk_lang/jtData/agentServer.47.trace -allowSetSecurityManager -port 44809 -timeoutFactor 10.0

Host: AMD EPYC 7742 64-Core Processor, 12 cores, 46G, Oracle Linux Server release 7.9
Time: Sun Apr 10 16:14:10 2022 UTC elapsed time: 202.118148 seconds (0d 0h 3m 22s)

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

Current thread (0x00007f4eb04eb730):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=15487, stack(0x00007f4e896a5000,0x00007f4e897a6000)]


Current CompileTask:
C2: 202118 16631   !b  4       Unsigned::testDivideAndRemainder (298 bytes)

Stack: [0x00007f4e896a5000,0x00007f4e897a6000],  sp=0x00007f4e897a20e0,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x133e4c4]  LibraryIntrinsic::generate(JVMState*)+0x284
V  [libjvm.so+0xc12e48]  Parse::do_call()+0x378
V  [libjvm.so+0x16a1458]  Parse::do_one_bytecode()+0x5f8
V  [libjvm.so+0x168ef74]  Parse::do_one_block()+0x864
V  [libjvm.so+0x168fed7]  Parse::do_all_blocks()+0x137
V  [libjvm.so+0x1694d66]  Parse::Parse(JVMState*, ciMethod*, float)+0xb96
V  [libjvm.so+0x8cbd90]  ParseGenerator::generate(JVMState*)+0x110
V  [libjvm.so+0xab5f1a]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x135a
V  [libjvm.so+0x8c97d3]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x683
V  [libjvm.so+0xac5d77]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc97
V  [libjvm.so+0xac6bd8]  CompileBroker::compiler_thread_loop()+0x718
V  [libjvm.so+0x195f22a]  JavaThread::thread_main_inner()+0x25a
V  [libjvm.so+0x196a550]  Thread::call_run()+0x100
V  [libjvm.so+0x1647f54]  thread_native_entry(Thread*)+0x104
Comments
The fix for this bug is integrated in jdk-19+19-1223.
15-04-2022
Changeset: a81c5d3a Author: vamsi-parasa <srinivas.vamsi.parasa@intel.com> Committer: Vladimir Kozlov <kvn@openjdk.org> Date: 2022-04-14 16:24:29 +0000 URL: https://git.openjdk.java.net/jdk/commit/a81c5d3a23163164a79763421935d0262a36f27e
14-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8190 Date: 2022-04-11 23:50:45 +0000
12-04-2022
Please see the fix submitted as PR at https://github.com/openjdk/jdk/pull/8190. Please let me know if there're any other issues. Thanks!
11-04-2022
Thank you for providing the information! I was able to reproduce the issue and will work on a fix and address this issue as early as possible.
11-04-2022
These checks were introduced by JDK-8262256. Similar issues have been fixed in the past (see JDK-8262998). The issue is easy to reproduce: public static void test() { Integer.divideUnsigned(0, 0); } public static void main(String[] args) { for (int i = 0; i < 100_000; ++i) { try { test(); } catch (Exception e) { } } }
11-04-2022
ILW = C2 emits intrinsic code even when bailing out (could lead to failures like JDK-8262231), with Integer intrinsics, disable affected intrinsic = MMM = P3
11-04-2022