JDK-8316414 : C2: large byte array clone triggers "failed: malformed control flow" assertion failure on linux-x86
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,17.0.10,20,21,22
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-09-18
  • Updated: 2024-02-21
  • Resolved: 2023-10-04
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 21 JDK 22
17.0.11-oracleFixed 21.0.2Fixed 22 b18Fixed
Related Reports
Relates :  
JDK-8292301 - [REDO v2] C2 crash when allocating array of size too large
Relates :  
JDK-8316512 - C2: large byte array clone crashes on linux-x86 for large FastAllocateSizeLimit values
Description
Running the attached program (Crash.java) on a 32-bits x86 debug VM using

$ java -Xcomp -XX:CompileOnly=Crash::createAndClone Crash.java

triggers the following assertion failure:

# A fatal error has been detected by the Java Runtime Environment:
#
#  src/hotspot/share/opto/compile.cpp:4004), pid=87530, tid=87544
#  assert(n->outcnt() == required_outcnt) failed: malformed control flow
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-internal-2023-09-18-0751569.roberto.castaneda.lozano.JDK-2215)
# Java VM: Java HotSpot(TM) Server VM (fastdebug 22-internal-2023-09-18-0751569.roberto.castaneda.lozano.JDK-2215, compiled mode, tiered, g1 gc, linux-x86)
# Problematic frame:
# V  [libjvm.so+0x80b4d7]  Compile::final_graph_reshaping()+0x757

The program creates and clones an array as large as allowed by arrayOopDesc::max_array_length(T_BYTE) on a 32-bits platform using default object alignment (8 bytes). The same assertion failure can be triggered for a 'short' array of 0x7ffffff8 elements.
Comments
Fix request [17u] I backport this for parity with 17.0.11-oracle. Simple change for C2, one platform only. Clean backport. Test passes, but also without the fix. SAP nightly testing passed.
30-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2089 Date: 2023-12-29 16:24:14 +0000
29-12-2023
[jdk21u-fix-request] Approval Request from Aleksey Shipilëv Clean backport to fix the C2 corner case. Patch applies cleanly. Unfortunately, the new test passes even without the fix, but the issue seems to be present anyway.
26-10-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u/pull/292 Date: 2023-10-25 15:55:10 +0000
25-10-2023
Right, the code was added around JDK-6711100 (or before), so 8u/11u are affected as well. I think it's not specific to 32-bit. [~roland], could you confirm?
06-10-2023
So, looking at the fix, it seems the oddity is not specific to 32 bits, and it has more affected versions than just 17..22. Right?
04-10-2023
Changeset: 0a3a925a Author: Roland Westrelin <roland@openjdk.org> Date: 2023-10-04 12:06:52 +0000 URL: https://git.openjdk.org/jdk/commit/0a3a925ad88921d387aa851157f54ac0054d347b
04-10-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15914 Date: 2023-09-26 08:46:40 +0000
26-09-2023
I have an environment where this reproduces, but I would not venture a guess where the bug is. This debugging hack: ``` --- a/src/hotspot/share/opto/compile.cpp +++ b/src/hotspot/share/opto/compile.cpp @@ -4001,6 +4001,10 @@ bool Compile::final_graph_reshaping() { required_outcnt--; } dead_nodes.push(valid_length_test); + if (n->outcnt() != required_outcnt) { + tty->print_cr("Required: %d", required_outcnt); + n->dump(-1); + } assert(n->outcnt() == required_outcnt, "malformed control flow"); continue; } ``` ...shows: ``` Required: 2 82 Catch === 79 124 [[ 84 ]] !jvms: Crash::createAndClone @ bci:6 (line 12) 84 CatchProj === 82 [[ 88 ]] #1@bci -1 !jvms: Crash::createAndClone @ bci:6 (line 12) ```
18-09-2023
[~thartmann] I will have a look
18-09-2023
That could well be. [~roland], what do you think?
18-09-2023
On 17u-dev, 17.0.6 works well and master fails. Bisected to JDK-8292301 backport, which actually added the assert. So I suspect JDK-8292301 is just broken with x86_32?
18-09-2023
Paging the 32-bit maintainers ([~shade]).
18-09-2023
Seems to be a regression somewhere between JDK 11u and 17u. I can reproduce the issue with 17.0.10 but not with 11.0.21. ILW = Assert during C2 compilation, single test with large array allocation on 32-bit, no workaround but disable compilation of affected method = HLM = P3
18-09-2023