JDK-8340214 : Crash in the C2 HotSpot Compiler Thread on JDK 21 fast debug mode
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P2
  • Status: New
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2024-09-13
  • Updated: 2024-09-17
Related Reports
Relates :  
JDK-8252372 - Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()
Relates :  
JDK-8336472 - C2: assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
Description
ADDITIONAL SYSTEM INFORMATION :
OpenJDK 64-Bit Server VM (fastdebug 21.0.5+5-Nightly) for linux-amd64
Redhat 8.9

A DESCRIPTION OF THE PROBLEM :
While we were upgrading from java 8 to java 21, we encountered an issue where some of the files that our code writes were corrupted. We traced that to a small method that transfers bytes from an Unsafe based Buffer to java.nioByteBuffer. This was happening right after the method got compiled by C2. We believe that after inlining and loop optimizations, the generated code is incorrect (the update positionAddress instruction was likely moved out of the loop). I think we've confirmed that when we got a crash report by using a fastdebug build of the Java21.

REGRESSION : Last worked in version 8u421

ACTUAL -
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/jenkins/node/workspace/Corretto21/generic_linux/x64/build/Corretto21Src/installers/linux/universal/tar/corretto-build/buildRoot/src/hotspot/share/opto/loopopts.cpp:1643), pid=3104989, tid=3105002
# assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
#
# JRE version: OpenJDK Runtime Environment Corretto-21.0.5.5.1 (21.0.5+5) (fastdebug build 21.0.5+5-Nightly)
# Java VM: OpenJDK 64-Bit Server VM Corretto-21.0.5.5.1 (fastdebug 21.0.5+5-Nightly, mixed mode, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x11fb779] PhaseIdealLoop::try_sink_out_of_loop(Node*)+0xc89
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e" (or dumping to xxx/core.3104989)
#
# If you would like to submit a bug report, please visit:
# https://github.com/corretto/corretto-21/issues/
#

---------- BEGIN SOURCE ----------
I haven't been able to create a small reproducer that doesn't use any of our internal code yet. The bug is pretty subtle. I am hoping that the hs_err report file could give us more insight into when it happens so that I can make a small executable test case. Is there any easy way to produce this, perhaps using the compiler replay functionality?
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Using either -XX:-SplitIfBlocks or -XX:CompileCommand=exclude,methodname

We also rewrote the code in a slightly different way so it no longer happens.


FREQUENCY : always
Comments
Regarding reproducing this with compiler replay: We would need the replay_pid*.log file + all the class files that are needed to replay the compilation. The reporter can check if the issue reproduces with: java XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid.log -XX:-CompactStrings -XX:+UseParallelGC -XX:-TieredCompilation -cp CLASSPATH It would also help to get more information about the affected JDK releases.
17-09-2024
[~fmatte] JDK-8294967 -> JDK-8288981 does not affect release builds and must therefore be a different issue. It's most likely another regression from JDK-8252372 in JDK 17 that had a huge bug tail. Unfortunately, there is not much we can do without a reproducer. It might be related to JDK-8336472 or one of the other bugs related to JDK-8252372 that we still have open.
17-09-2024
Similar one of JDK-8288981
16-09-2024