JDK-8303512 : Race condition when computing is_loaded property of TypePtr::InterfaceSet
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-03-02
  • Updated: 2023-07-10
  • Resolved: 2023-05-15
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 21
21 b23Fixed
Related Reports
Duplicate :  
JDK-8305339 - fatal error: meet not symmetric
Relates :  
JDK-8293841 - RISC-V: Implementation of Foreign Function & Memory API (Preview)
Relates :  
JDK-8307625 - Redundant receiver null check in LibraryCallKit::generate_method_call
Relates :  
JDK-8297933 - [REDO] Compiler should only use verified interface types for optimization
Description
The test java/foreign/callarranger/TestRISCV64CallArranger.java crashes with SIGSEGV (within LibraryCallKit::generate_method_call) on macosx-x64, see attached HotSpot error file. The failure is observed on a Generational ZGC build, but it is unlikely to be Generational ZGC-specific. I failed to reproduce the crash using compilation replay.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010a9c5306, pid=79781, tid=29955
#
# JRE version: Java(TM) SE Runtime Environment (21.0+4) (build 21-genzgc+4-LTS-29)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21-genzgc+4-LTS-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x7d5306]  LibraryCallKit::generate_method_call(vmIntrinsicID, bool, bool)+0x386

Current CompileTask:
C2:    762 1086       4       java.lang.invoke.MethodType::hashCode (53 bytes)

Stack: [0x0000700009a42000,0x0000700009b42000],  sp=0x0000700009b3fc30,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x7d5306]  LibraryCallKit::generate_method_call(vmIntrinsicID, bool, bool)+0x386
V  [libjvm.dylib+0x7b297e]  LibraryCallKit::inline_native_hashcode(bool, bool)+0xf7e
V  [libjvm.dylib+0x7af787]  LibraryCallKit::try_to_inline(int)+0x207
V  [libjvm.dylib+0x7af1f0]  LibraryIntrinsic::generate(JVMState*)+0xa0
V  [libjvm.dylib+0x45c14c]  Parse::do_call()+0x5ac
V  [libjvm.dylib+0x9576d8]  Parse::do_one_block()+0x218
V  [libjvm.dylib+0x956662]  Parse::do_all_blocks()+0x4e2
V  [libjvm.dylib+0x954076]  Parse::Parse(JVMState*, ciMethod*, float)+0x806
V  [libjvm.dylib+0x2d4a70]  ParseGenerator::generate(JVMState*)+0x80
V  [libjvm.dylib+0x384d7e]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xcbe
V  [libjvm.dylib+0x2d2c1f]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xef
V  [libjvm.dylib+0x3984ca]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4ca
V  [libjvm.dylib+0x397f5c]  CompileBroker::compiler_thread_loop()+0x4ec
V  [libjvm.dylib+0x5c3524]  JavaThread::thread_main_inner()+0x94
V  [libjvm.dylib+0xad5495]  Thread::call_run()+0xa5
V  [libjvm.dylib+0x934cd7]  thread_native_entry(Thread*)+0x147
C  [libsystem_pthread.dylib+0x6259]  _pthread_start+0x7d
C  [libsystem_pthread.dylib+0x1c7b]  thread_start+0xf

Should this test be enabled at all on other platforms than RISCV64?
Comments
Changeset: ad348a8c Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2023-05-15 11:06:20 +0000 URL: https://git.openjdk.org/jdk/commit/ad348a8cec50561d3e295b6289772530f541c6b1
15-05-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13868 Date: 2023-05-08 14:52:21 +0000
08-05-2023
This is a regression from JDK-8297933 and the root cause is a race condition among compiler threads computing TypePtr::InterfaceSet::_is_loaded for a shared type. One thread can set _is_loaded_computed before setting _is_loaded while another thread can already access _is_loaded (and wrongly observe _is_loaded = false). As a result, the klass of a TypePtr can be loaded while the interfaces it implements appear to be not loaded. Another problem is that TypePtr::InterfaceSet::eq does not take the _is_loaded / _is_loaded_computed fields into account. A loaded type can therefore be replaced by an unloaded type during GVN. In the case of the failure reported by this bug, LibraryCallKit::inline_native_hashcode first null checks the receiver and updates the type. Due to the issues described above, the null-free type is GVN'ed with it's unloaded counterpart and propagated to another, redundant null check emitted by LibraryCallKit::generate_method_call. Since the type is now unloaded, an uncommon trap is emitted and parsing is stopped(). We crash when trying to de-reference GraphKit::_map->_jvms which is NULL. Another failure mode is reported by JDK-8305339.
08-05-2023
I think this is related to JDK-8305339. I added more information there.
05-05-2023
I executed several thousand iterations of the failing tests (even with the same build and on the same machine) but I'm not able to reproduce this.
24-03-2023
Here's the crashing thread's stack from the jdk-21+15-1172-tier1 sighting: java/lang/ModuleLayer/automatic/AutomaticModulesTest.java --------------- T H R E A D --------------- Current thread (0x00007fbbb3974c00): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=22787, stack(0x000070000a4e1000,0x000070000a5e1000)] Current CompileTask: C2: 2057 1753 4 java.lang.invoke.MethodType::hashCode (53 bytes) Stack: [0x000070000a4e1000,0x000070000a5e1000], sp=0x000070000a5deb90, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x7bae86] LibraryCallKit::generate_method_call(vmIntrinsicID, bool, bool)+0x386 V [libjvm.dylib+0x7984fe] LibraryCallKit::inline_native_hashcode(bool, bool)+0xf7e V [libjvm.dylib+0x795307] LibraryCallKit::try_to_inline(int)+0x207 V [libjvm.dylib+0x794d70] LibraryIntrinsic::generate(JVMState*)+0xa0 V [libjvm.dylib+0x4523dc] Parse::do_call()+0x5ac V [libjvm.dylib+0x939ed8] Parse::do_one_block()+0x218 V [libjvm.dylib+0x938e62] Parse::do_all_blocks()+0x4e2 V [libjvm.dylib+0x936876] Parse::Parse(JVMState*, ciMethod*, float)+0x806 V [libjvm.dylib+0x2cf620] ParseGenerator::generate(JVMState*)+0x80 V [libjvm.dylib+0x37bd9e] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xcbe V [libjvm.dylib+0x2cd7ef] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xef V [libjvm.dylib+0x38f67a] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4ca V [libjvm.dylib+0x38f0fc] CompileBroker::compiler_thread_loop()+0x5ec V [libjvm.dylib+0x5b33a4] JavaThread::thread_main_inner()+0x94 V [libjvm.dylib+0xab3a15] Thread::call_run()+0xa5 V [libjvm.dylib+0x917d67] thread_native_entry(Thread*)+0x147 C [libsystem_pthread.dylib+0x6259] _pthread_start+0x7d C [libsystem_pthread.dylib+0x1c7b] thread_start+0xf siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000038
16-03-2023
After some more staring at the code, I'm still not sure how this can happen. Although we seem to be missing a stopped() check after the null_check_receiver() checks in LibraryCallKit::generate_method_call(), this should never be possible because we check the receiver for null before that in LibraryCallKit::inline_native_hashcode. I'm closing this as Cannot Reproduce for now, hoping it shows up again in a more reproducible form.
10-03-2023
Thanks [~fjiang], the issue seems to be platform independent and from the stack trace on Linux x86, it looks like we crash in callnode.hpp:247, which would be JVMState::bci(). Probably, the JVMState is NULL. Seems we are missing a stopped() check after null_check_receiver(), maybe that's the issue. I'll try to verify.
03-03-2023
[~thartmann] Seems it's not related to foreign API, but I can help to run tests on linux-riscv to see if this issue also happens on riscv. > Should this test be enabled at all on other platforms than RISCV64? Looks like CallArrangerTest just tests how the function arguments and return values passed. Though it has platform-dependent implementations, they are all Java code, so I think it's okay to enable the test on other platforms.
03-03-2023
This also happened once with a completely different test on Linux x86_64 that is not using panama/foreign memory API: java/net/httpclient/ManyRequests.java Current CompileTask: C2: 1058 1135 4 java.lang.invoke.MethodType::hashCode (53 bytes) Stack: [0x00007f74635f5000,0x00007f74636f6000], sp=0x00007f74636f2980, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xb24f58] LibraryCallKit::generate_method_call(vmIntrinsicID, bool, bool)+0x208 (callnode.hpp:247) V [libjvm.so+0xb26d57] LibraryCallKit::inline_native_hashcode(bool, bool)+0x1007 (library_call.cpp:4344) V [libjvm.so+0xb2b04c] LibraryIntrinsic::generate(JVMState*)+0x15c (library_call.cpp:116) V [libjvm.so+0x70d908] Parse::do_call()+0x1f8 (doCall.cpp:662) V [libjvm.so+0xcd1af8] Parse::do_one_block()+0x208 (parse1.cpp:1560) V [libjvm.so+0xcd1f25] Parse::do_all_blocks()+0xe5 (parse1.cpp:707) V [libjvm.so+0xcd4675] Parse::Parse(JVMState*, ciMethod*, float)+0x725 (parse1.cpp:613) V [libjvm.so+0x55710b] ParseGenerator::generate(JVMState*)+0x8b (callGenerator.cpp:99) V [libjvm.so+0x624975] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xd75 (compile.cpp:763) V [libjvm.so+0x556210] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x120 (c2compiler.cpp:113) V [libjvm.so+0x62bb5f] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa6f (compileBroker.cpp:2237) V [libjvm.so+0x62c9e8] CompileBroker::compiler_thread_loop()+0x558 (compileBroker.cpp:1916) V [libjvm.so+0x8d8a18] JavaThread::thread_main_inner() [clone .part.0]+0xb8 (javaThread.cpp:710) V [libjvm.so+0xe76f16] Thread::call_run()+0xa6 (thread.cpp:224) V [libjvm.so+0xca2948] thread_native_entry(Thread*)+0xd8 (os_linux.cpp:737)
02-03-2023
Not sure what happened here and unfortunately, there is no core file to investigate. ILW = Crash during intrinsification in C2 compilation, only happened once, no workaround but disable intrinsic or compilation of affected method = HLM = P3
02-03-2023