JDK-8277529 : SIGSEGV in C2 CompilerThread Node::rematerialize() compiling Packet::readUnsignedTrint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.14,11.0.14-oracle,17.0.2,18
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-11-22
  • Updated: 2021-12-09
  • Resolved: 2021-12-03
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 17 JDK 18
11.0.14-oracleFixed 17.0.2Fixed 18 b27Fixed
Related Reports
Relates :  
JDK-8272574 - C2: assert(false) failed: Bad graph detected in build_loop_late
Relates :  
JDK-8146792 - Predicate moved after partial peel may lead to broken graph
Relates :  
JDK-8252372 - Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()
Relates :  
JDK-8278231 - C2: Cleanup loop invariance handling for data nodes dependent on projection into the loop
Relates :  
JDK-8278230 - C2: Improve control of pinned loads split through phis to enable loop predication later
Description
Manifestation with replay file and debug build:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tank/fmatte/repos/git/jdk17u-cpu/open/src/hotspot/share/opto/loopnode.cpp:5031), pid=31995, tid=32008
#  assert(s1->is_Proj()) failed: projection expected
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-11-22-0852176.fmatte...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-11-22-0852176.fmatte..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1322f55]  PhaseIdealLoop::get_late_ctrl_with_anti_dep(LoadNode*, Node*, Node*)+0x8b5
..........
Current thread (0x00007fe4fc27f580):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=32008, stack(0x00007fe4870ee000,0x00007fe4871ef000)]

Current CompileTask:
C2:   1324   20    b  4       com.tangosol.coherence.component.net.Packet::readUnsignedTrint (43 bytes)

Stack: [0x00007fe4870ee000,0x00007fe4871ef000],  sp=0x00007fe4871e90d0,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1322f55]  PhaseIdealLoop::get_late_ctrl_with_anti_dep(LoadNode*, Node*, Node*)+0x8b5
V  [libjvm.so+0x13238a1]  PhaseIdealLoop::get_late_ctrl(Node*, Node*)+0x121
V  [libjvm.so+0x1323b6d]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x22d
V  [libjvm.so+0x13240ea]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xba
V  [libjvm.so+0x1324a57]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x507
V  [libjvm.so+0xa37aaa]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x2da
V  [libjvm.so+0xa33456]  Compile::Optimize()+0x586
V  [libjvm.so+0xa35f48]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x1618
V  [libjvm.so+0x84b356]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x646
V  [libjvm.so+0xa45f91]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb71
V  [libjvm.so+0xa46c38]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x18dd961]  JavaThread::thread_main_inner()+0x271
V  [libjvm.so+0x18e4f50]  Thread::call_run()+0x100
V  [libjvm.so+0x15aaca4]  thread_native_entry(Thread*)+0x104
Comments
Hello Vladimir, thanks! Good to see that both backport PRs are identical. I think we should ship it with 11.0.14 if possible.
09-12-2021
Hello Martin, looks like we had a "race condition" when started working this bug https://github.com/openjdk/jdk11u-dev/pull/692 anyway, if your backport will get approved for critical request then I will withdraw mine.
08-12-2021
Fix Request (11u): Fix was backported to 11.0.14-oracle, but is missing in OpenJDK 11.0.14. The 17u backport version applies almost cleanly. Review: https://github.com/openjdk/jdk11u/pull/21
08-12-2021
fixed in Update, no BPR needed
06-12-2021
Changeset: 01cb2b98 Author: Christian Hagedorn <chagedorn@openjdk.org> Date: 2021-12-03 17:14:10 +0000 URL: https://git.openjdk.java.net/jdk/commit/01cb2b9883d7c9ecdba0ee5bd42124faed4d080c
03-12-2021
I could extract a testcase from the reproducer and I'm now testing a fix over night. It turned out that we are updating the control input of a data node directly to an ArrayCopy node when splitting a load through a region (new code added by JDK-8272574). This is illegal and is later found with the assertion reported by [~fmatte] above. With JDK-8272574, we set the control input of the split load to the same control input as the memory input into the phi belonging to the region through which we split which is a projection of an ArrayCopy node. The first thought was to update the fix done by JDK-8272574 to disallow the improved rewiring if the memory input into the phi is a projection. However, this did not seem correct to me and I modified the reproducer further. I found a case where we hit the new assertion added by JDK-8272574 with this initial fix attempt. During this investigation I found that JDK-8146792 actually forbids the application of loop predicates all together if we have a data node that is dependent on the projection into a loop. This, however, does not work correctly and we end up with the case described in the review of JDK-8272574. Therefore, my fix aims to improve fix done in JDK-8146792 to properly bail out of loop predication for the cases reported with JDK-8272574 and the reproducer(s) for this bug and actually undo the fix of JDK-8272574.
01-12-2021
Unassigning myself, as issue is present in jdk18 also.
23-11-2021
Though the fix of JDK-8272574 went in jdk11.0.14-b01, it is not reproducible on 11.0.14-b05. Failing code is added with this JDK-8252372, which is not in jdk11.0.14.
23-11-2021
Issue is also reproducible on jdk18 b24 == # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/opt/mach5/mesos/work_dir/slaves/a2dc162d-743b-4800-9e92-31f85abb45b1-S136831/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a80cce1f-d132-4846-bad4-eefe7a994513/runs/49c40ce9-22c4-4b24-84c9-df1aee40b98d/workspace/open/src/hotspot/share/opto/loopnode.cpp:5272), pid=23625, tid=24290 # assert(s1->is_Proj()) failed: projection expected # # JRE version: Java(TM) SE Runtime Environment (18.0+24) (fastdebug build 18-ea+24-1608) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+24-1608, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x137f245] PhaseIdealLoop::get_late_ctrl_with_anti_dep(LoadNode*, Node*, Node*)+0x8b5 # # 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 /scratchr/core.23625) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp
23-11-2021
ILW = Segfault (assertion failure with debug build) in C2 compiler and recent regression, seems intermittent, disable compilation of affected method = HMM = P2
22-11-2021
Able to reproduce with replay data file == # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:5031 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/tank/fmatte/repos/git/jdk17u-cpu/open/src/hotspot/share/opto/loopnode.cpp:5031), pid=31995, tid=32008 # assert(s1->is_Proj()) failed: projection expected # # JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-LTS-2021-11-22-0852176.fmatte...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-LTS-2021-11-22-0852176.fmatte..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x1322f55] PhaseIdealLoop::get_late_ctrl_with_anti_dep(LoadNode*, Node*, Node*)+0x8b5 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /tank/fmatte/bugdb/33590597/core.31995) # # An error report file with more information is saved as: # /tank/fmatte/bugdb/33590597/hs_err_pid31995.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp ==
22-11-2021