JDK-8357402 : Crash in AdapterHandlerLibrary::lookup
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2025-05-21
  • Updated: 2025-07-24
  • Resolved: 2025-05-22
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 25
25 b25Fixed
Related Reports
Relates :  
Description
In our testing we hit next crash 

# SIGSEGV (0xb) at pc=0x00007fbbc03c4810, pid=2232216, tid=2232247
#
# JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-internal-LTS-2025-05-19-0416342.jdk25.jep515)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-05-19-0416342.jdk25.jep515, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x18f5810] AdapterHandlerLibrary::lookup(int, BasicType*)+0x3b0
#

Current CompileTask:
C1:1362 289 2 java.lang.invoke.VarHandleGuards::guard_LI_I (78 bytes)

Stack: [0x00007fbba05ae000,0x00007fbba06ae000], sp=0x00007fbba06aae40, free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x18f5810] AdapterHandlerLibrary::lookup(int, BasicType*)+0x3b0
V [libjvm.so+0x18f8254] AdapterHandlerLibrary::get_adapter(methodHandle const&)+0x2f4
V [libjvm.so+0x1636acd] Method::make_adapters(methodHandle const&, JavaThread*)+0x6d
V [libjvm.so+0x1636e1b] Method::link_method(methodHandle const&, JavaThread*)+0x24b
V [libjvm.so+0x163d611] Method::make_method_handle_intrinsic(vmIntrinsicID, Symbol*, JavaThread*)+0x671
V [libjvm.so+0x1a54653] SystemDictionary::find_method_handle_intrinsic(vmIntrinsicID, Symbol*, JavaThread*)+0x1b3
V [libjvm.so+0x147bf97] LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*, JavaThread*)+0x6b7
V [libjvm.so+0x147ea44] LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, JavaThread*)+0x694
V [libjvm.so+0x1482884] LinkResolver::linktime_resolve_virtual_method(LinkInfo const&, JavaThread*)+0x34
V [libjvm.so+0x1482cf9] LinkResolver::linktime_resolve_virtual_method_or_null(LinkInfo const&)+0x39
V [libjvm.so+0x9ddf39] ciEnv::lookup_method(ciInstanceKlass*, ciKlass*, Symbol*, Symbol*, Bytecodes::Code, constantTag)+0x1d9
V [libjvm.so+0x9de33b] ciEnv::get_method_by_index_impl(constantPoolHandle const&, int, Bytecodes::Code, ciInstanceKlass*)+0x1cb
V [libjvm.so+0xa4aadc] ciBytecodeStream::get_method(bool&, ciSignature**)+0x13c
V [libjvm.so+0x83e6e7] GraphBuilder::invoke(Bytecodes::Code)+0x37
V [libjvm.so+0x840747] GraphBuilder::iterate_bytecodes_for_block(int)+0xc07
V [libjvm.so+0x843bca] GraphBuilder::iterate_all_blocks(bool)+0x8a
V [libjvm.so+0x845772] GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0xa72
V [libjvm.so+0x854418] IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x3d8
V [libjvm.so+0x8545da] IR::IR(Compilation*, ciMethod*, int)+0xaa
V [libjvm.so+0x81ce39] Compilation::build_hir() [clone .part.0]+0x199
V [libjvm.so+0x81f1c8] Compilation::compile_java_method()+0x508
V [libjvm.so+0x81f9c6] Compilation::compile_method()+0x266
V [libjvm.so+0x82018d] Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35d
V [libjvm.so+0x821aff] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1ff
V [libjvm.so+0xb38878] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb58
V [libjvm.so+0xb39a48] CompileBroker::compiler_thread_loop()+0x578
V [libjvm.so+0x108543b] JavaThread::thread_main_inner()+0x13b
V [libjvm.so+0x1ab51d6] Thread::call_run()+0xb6
V [libjvm.so+0x1743a58] thread_native_entry(Thread*)+0x128

Comments
Changeset: b1b786a3 Branch: master Author: Vladimir Kozlov <kvn@openjdk.org> Date: 2025-05-22 18:59:37 +0000 URL: https://git.openjdk.org/jdk/commit/b1b786a3be9774662424a629c0ad5d1260efc597
22-05-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25398 Date: 2025-05-22 17:13:05 +0000
22-05-2025

ILW = Crash when getting adapter, recent regression - medium?, use -XX:-AOTAdapterCaching? = HMM = P2
22-05-2025

We should not access _aot_adapter_handler_table during dump (it is used only in production run). The access to it is guarded by (!AOTCodeCache::is_dumping_adapter()): https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/sharedRuntime.cpp Unfortunately this check will return false when we close AOT Code Cache after dumping it so that `is_on()` is false: bool AOTCodeCache::is_dumping_adapter() { return AOTAdapterCaching && is_on_for_dump(); } We should guard access to _aot_adapter_handler_table with `is_using_adapter()` check instead.
21-05-2025

I was not able to reproduce it locally but based on output the crash happened during accessing `_aot_adapter_handler_table.lookup()` after we dumped archive ands AOT code cache is closed: Event: 0.751 Executing safepoint VM operation: PopulateDumpSharedSpace Event: 1.337 Executing safepoint VM operation: PopulateDumpSharedSpace done The output has overlap of failure report and dump info about archive: # V [libjvm.so+0x18f5810][1.359s][info][cds ] Shared file region (ac) 4: 468640 bytes, addr 0x0000000800a9f000 file offset 0x00a9f000 crc 0x0f3859fe AdapterHandlerLibrary::lookup(int, BasicType*)+0x3b0
21-05-2025