JDK-8320308 : C2 compilation crashes in LibraryCallKit::inline_unsafe_access
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13,17,21,22,23,24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-11-17
  • Updated: 2024-10-07
  • Resolved: 2024-10-01
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 24
24 b18Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Sub Tasks
JDK-8340707 :  
Description
The new -XX:+StressIncrementalInlining flag introduced by JDK-8319879 triggers the following extremely intermittent assert with java/foreign/TestByteBuffer.java and -XX:+UnlockDiagnosticVMOptions -XX:+StressIncrementalInlining:

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb4330c539, pid=92580, tid=118028
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (build 22-internal-2023-11-17-0923175.tobias.hartmann.jdk3)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (22-internal-2023-11-17-0923175.tobias.hartmann.jdk3, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x5dc539]  LibraryCallKit::inline_unsafe_access+0x2c9
#

Current CompileTask:
C2:1693 1688       4       TestByteBuffer$$Lambda/0x000001d3110a53a8::apply (12 bytes)

Stack: [0x0000001a8a200000,0x0000001a8a300000],  sp=0x0000001a8a2fb640,  free space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x5dc539]  LibraryCallKit::inline_unsafe_access+0x2c9  (library_call.cpp:2387)
V  [jvm.dll+0x5e0fff]  LibraryCallKit::try_to_inline+0x65f  (library_call.cpp:766)
V  [jvm.dll+0x5ca9d4]  LibraryIntrinsic::generate+0x94  (library_call.cpp:117)
V  [jvm.dll+0x2f5c7f]  Parse::do_call+0x53f  (doCall.cpp:675)
V  [jvm.dll+0x6f8b47]  Parse::do_one_bytecode+0x3007  (parse2.cpp:2729)
V  [jvm.dll+0x6f0e95]  Parse::do_one_block+0x175  (parse1.cpp:1578)
V  [jvm.dll+0x6f0337]  Parse::do_all_blocks+0x367  (parse1.cpp:716)
V  [jvm.dll+0x6ee50c]  Parse::Parse+0x67c  (parse1.cpp:620)
V  [jvm.dll+0x1cb7ac]  ParseGenerator::generate+0x8c  (callGenerator.cpp:100)
V  [jvm.dll+0x1cc32b]  PredictedCallGenerator::generate+0x26b  (callGenerator.cpp:921)
V  [jvm.dll+0x1c9e12]  CallGenerator::do_late_inline_helper+0x562  (callGenerator.cpp:698)
V  [jvm.dll+0x253268]  Compile::inline_incrementally_one+0xf8  (compile.cpp:2036)
V  [jvm.dll+0x252b78]  Compile::inline_incrementally+0x238  (compile.cpp:2117)
V  [jvm.dll+0x24bcdd]  Compile::Optimize+0x2ad  (compile.cpp:2254)
V  [jvm.dll+0x24a286]  Compile::Compile+0xd66  (compile.cpp:855)
V  [jvm.dll+0x1c85e0]  C2Compiler::compile_method+0x110  (c2compiler.cpp:137)
V  [jvm.dll+0x259cde]  CompileBroker::invoke_compiler_on_method+0x7ee  (compileBroker.cpp:2295)
V  [jvm.dll+0x2581ba]  CompileBroker::compiler_thread_loop+0x26a  (compileBroker.cpp:1952)
V  [jvm.dll+0x3f58d6]  JavaThread::run+0x116  (javaThread.cpp:705)
V  [jvm.dll+0x81739b]  Thread::call_run+0xcb  (thread.cpp:230)
V  [jvm.dll+0x6dcc25]  thread_native_entry+0x95  (os_windows.cpp:553)
C  [ucrtbase.dll+0x26c0c]  (no source info available)
C  [KERNEL32.DLL+0x154e0]  (no source info available)
C  [ntdll.dll+0x485b]  (no source info available)

I can only reproduce it with release builds. The problem is that alias_type->adr_type() is NULL.
Comments
Changeset: 8d6d37fe Branch: master Author: Tobias Holenstein <tholenstein@openjdk.org> Date: 2024-10-01 23:52:46 +0000 URL: https://git.openjdk.org/jdk/commit/8d6d37fea133380d4143f5db38ad3790efa84f68
01-10-2024

With JDK-8335334, the stress seed is initialized earlier which triggers this issue more frequently. We had to problem list applications/ctw/modules/java_base.java (see JDK-8340707) which needs to be undone with this fix.
24-09-2024

Newest test reproduces the issue since JDK 13 b7, looks like a side effect of JDK-8059241. The problem goes away with -XX:+IncrementalInlineForceCleanup. I updated the affects versions.
10-07-2024

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20033 Date: 2024-07-04 12:17:51 +0000
09-07-2024

I also hit this when testing with -XX:+StressUnstableIfTraps (JDK-8335334). Attached replay_modules_java_base_0_2180219.log reproduces the issue reliably: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007feb4371ddf4, pid=445192, tid=445206 # # JRE version: Java(TM) SE Runtime Environment (24.0) (fastdebug build 24-internal-2024-07-01-1030594.tobias...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-internal-2024-07-01-1030594.tobias..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x11f6df4] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x744 Current CompileTask: C2:695 51 b 4 java.lang.invoke.VarHandleSegmentAsFloats::get (48 bytes) Stack: [0x00007feb15cfd000,0x00007feb15dfe000], sp=0x00007feb15df7dc0, free space=1003k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11f6df4] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x744 (type.hpp:2070) V [libjvm.so+0x121f394] LibraryIntrinsic::generate(JVMState*)+0x1e4 (library_call.cpp:118) V [libjvm.so+0xb6de42] Parse::do_call()+0x602 (doCall.cpp:675) V [libjvm.so+0x14fa348] Parse::do_one_bytecode()+0x328 (parse2.cpp:2790) V [libjvm.so+0x14e7b3a] Parse::do_one_block()+0x20a (parse1.cpp:1594) V [libjvm.so+0x14e8ff6] Parse::do_all_blocks()+0x136 (parse1.cpp:721) V [libjvm.so+0x14ec838] Parse::Parse(JVMState*, ciMethod*, float)+0xa98 (parse1.cpp:625) V [libjvm.so+0x835d89] ParseGenerator::generate(JVMState*)+0x169 (callGenerator.cpp:99) V [libjvm.so+0x83983a] PredictedCallGenerator::generate(JVMState*)+0x3aa (callGenerator.cpp:928) V [libjvm.so+0xb6de42] Parse::do_call()+0x602 (doCall.cpp:675) V [libjvm.so+0x14fa348] Parse::do_one_bytecode()+0x328 (parse2.cpp:2790) V [libjvm.so+0x14e7b3a] Parse::do_one_block()+0x20a (parse1.cpp:1594) V [libjvm.so+0x14e8ff6] Parse::do_all_blocks()+0x136 (parse1.cpp:721) V [libjvm.so+0x14ec838] Parse::Parse(JVMState*, ciMethod*, float)+0xa98 (parse1.cpp:625) V [libjvm.so+0x835d89] ParseGenerator::generate(JVMState*)+0x169 (callGenerator.cpp:99) V [libjvm.so+0x83983a] PredictedCallGenerator::generate(JVMState*)+0x3aa (callGenerator.cpp:928) V [libjvm.so+0x83b877] CallGenerator::do_late_inline_helper()+0x9f7 (callGenerator.cpp:704) V [libjvm.so+0x9da534] Compile::inline_incrementally_one()+0xd4 (compile.cpp:2031) V [libjvm.so+0x9db282] Compile::inline_incrementally(PhaseIterGVN&)+0x292 (compile.cpp:2114) V [libjvm.so+0x9dd280] Compile::Optimize()+0x340 (compile.cpp:2249) V [libjvm.so+0x9e14bf] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1b1f (compile.cpp:852) V [libjvm.so+0x833b05] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1d5 (c2compiler.cpp:142) V [libjvm.so+0x9ed0f8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x928 (compileBroker.cpp:2303) V [libjvm.so+0x9edd88] CompileBroker::compiler_thread_loop()+0x478 (compileBroker.cpp:1961) V [libjvm.so+0xe9785c] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:757) V [libjvm.so+0x17b5df6] Thread::call_run()+0xb6 (thread.cpp:225) V [libjvm.so+0x149ef47] thread_native_entry(Thread*)+0x127 (os_linux.cpp:858)
09-07-2024

ILW = Crash during C2 compilation, single test with stress flag, disable inline_unsafe_intrinsic = HLM = P3
17-11-2023