JDK-8357047 : [ubsan] AdapterFingerPrint::AdapterFingerPrint runtime error: index 3 out of bounds
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • CPU: aarch64
  • Submitted: 2025-05-15
  • Updated: 2025-05-19
Description
When running some jtreg tests on macOS aarch64 e.g.
java/awt/image/BufferedImage/TinyScale.java
we see this issue with ubsan enabled binaries :

/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:2211:7: runtime error: index 3 out of bounds for type 'int[3]'
    #0 0x107b04618 in AdapterFingerPrint::AdapterFingerPrint(int, BasicType*) sharedRuntime.cpp:2211
    #1 0x107afaad0 in AdapterHandlerLibrary::lookup(int, BasicType*) sharedRuntime.cpp:2454
    #2 0x107afbfcc in AdapterHandlerLibrary::get_adapter(methodHandle const&) sharedRuntime.cpp:2741
    #3 0x1078c7be4 in Method::make_adapters(methodHandle const&, JavaThread*) method.cpp:1252
    #4 0x1078c7960 in Method::link_method(methodHandle const&, JavaThread*) method.cpp:1225
    #5 0x1073a11a8 in InstanceKlass::link_methods(JavaThread*) instanceKlass.cpp:1090
    #6 0x1073a0c98 in InstanceKlass::link_class_impl(JavaThread*) instanceKlass.cpp:1017
    #7 0x1073a0320 in InstanceKlass::link_class(JavaThread*) instanceKlass.cpp:899
    #8 0x10739eec4 in InstanceKlass::initialize_impl(JavaThread*) instanceKlass.cpp:1184
    #9 0x10739ee10 in InstanceKlass::initialize(JavaThread*) instanceKlass.cpp:814
    #10 0x1073d3d58 in InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) interpreterRuntime.cpp:219
    #11 0x137548050  (<unknown module>)
    #12 0x137534150  (<unknown module>)
    #13 0x1073eaf54 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415
    #14 0x1073a2500 in InstanceKlass::call_class_initializer(JavaThread*) instanceKlass.cpp:1707
    #15 0x10739f9d8 in InstanceKlass::initialize_impl(JavaThread*) instanceKlass.cpp:1316
    #16 0x10739ee10 in InstanceKlass::initialize(JavaThread*) instanceKlass.cpp:814
    #17 0x10773e0dc in LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*) linkResolver.cpp:1115
    #18 0x107741280 in LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*) linkResolver.cpp:1744
    #19 0x107741160 in LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*) linkResolver.cpp:1703
    #20 0x1073d7340 in InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) interpreterRuntime.cpp:819
    #21 0x1073d83cc in InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code) interpreterRuntime.cpp:998
    #22 0x137546f00  (<unknown module>)
    #23 0x13753881c  (<unknown module>)
    #24 0x13753881c  (<unknown module>)
    #25 0x13753881c  (<unknown module>)
    #26 0x137538a8c  (<unknown module>)
    #27 0x137538a8c  (<unknown module>)
    #28 0x137538a8c  (<unknown module>)
    #29 0x13753881c  (<unknown module>)
    #30 0x13753881c  (<unknown module>)
    #31 0x13753881c  (<unknown module>)
    #32 0x137538dbc  (<unknown module>)
    #33 0x13753881c  (<unknown module>)
    #34 0x13753902c  (<unknown module>)
    #35 0x137538a8c  (<unknown module>)
    #36 0x137534150  (<unknown module>)
    #37 0x1073eaf54 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415
    #38 0x1073e9ab0 in JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) javaCalls.cpp:179
    #39 0x1073e9bdc in JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) javaCalls.cpp:185
    #40 0x107515984 in thread_entry(JavaThread*, JavaThread*) jvm.cpp:2748
    #41 0x1074154d4 in JavaThread::thread_main_inner() javaThread.cpp:772
    #42 0x107415094 in JavaThread::run() javaThread.cpp:757
    #43 0x107e11080 in Thread::call_run() thread.cpp:224
    #44 0x10798fde8 in thread_native_entry(Thread*) os_bsd.cpp:597
    #45 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #46 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
Comments
> I guess I am missing some libraries here. You need most likely an additional system package. On my SUSE Linux box (however x86_64) I have both libubsan0 and libubsan1 packages installed ; not sure what distro you are using but I guess you have similar named package(s) for your Linux . We might add some checking for these ubsan-support packages to configure if --enable-ubsan is configured ; at least we have this for some other build deps of OpenJDK (there we check the existence and give some helpful output for at least the major distros).
16-05-2025

[~mbaesken] is there any doc on building hotspot with ubsan? I installed clang on linux aarch64 and configured it as: # bash ./configure --with-debug-level=slowdebug --with-native-debug-symbols=internal --enable-ubsan --with-toolchain-type=clang --with-conf-name=... but "make images" failed as: === Output from failing command(s) repeated here === * For target hotspot_variant-server_tools_adlc_objs_BUILD_ADLC_run_ld: ld.lld: error: cannot open /usr/lib64/clang/16/lib/linux/libclang_rt.ubsan_standalone-aarch64.a: No such file or directory ld.lld: error: cannot open /usr/lib64/clang/16/lib/linux/libclang_rt.ubsan_standalone_cxx-aarch64.a: No such file or directory clang-16: error: linker command failed with exit code 1 (use -v to see invocation) I guess I am missing some libraries here.
16-05-2025

Hi [~asmehra] thanks for looking into it ! Maybe you can see the error also on Linux aarch64 and not only macOS with clang set as compiler (but with gcc our tests so far did not show it, maybe ubsan works a little different with clang than gcc).
16-05-2025

[~mbaesken] Thanks for testing out the fix. I should have checked the code for places that access _value directly. There are two more such occurrences. I will update and let you know when it is ready.
16-05-2025

> here is my proposed fix: https://github.com/openjdk/jdk/compare/master...ashu-mehra:jdk:JDK-8357047 Let me know if you can test it out. When applying your fix and running java/awt/image/BufferedImage/TinyScale.java , the issue reported above goes away ; but another occurs also most likely related to the recent sharedRuntime.cpp changes : /jdk/src/hotspot/share/runtime/sharedRuntime.cpp:2299:12: runtime error: index 3 out of bounds for type 'int[3]' #0 0x105f04c18 in AdapterFingerPrint::value(int) sharedRuntime.cpp:2299 #1 0x105efaeec in AdapterFingerPrint::compute_hash() sharedRuntime.cpp:2314 #2 0x105efa978 in AdapterHandlerLibrary::lookup(int, BasicType*) sharedRuntime.cpp:2466 #3 0x105efbe6c in AdapterHandlerLibrary::get_adapter(methodHandle const&) sharedRuntime.cpp:2746 #4 0x105cc7a84 in Method::make_adapters(methodHandle const&, JavaThread*) method.cpp:1252 #5 0x105cc7800 in Method::link_method(methodHandle const&, JavaThread*) method.cpp:1225 #6 0x1057a10e8 in InstanceKlass::link_methods(JavaThread*) instanceKlass.cpp:1090 #7 0x1057a0bd8 in InstanceKlass::link_class_impl(JavaThread*) instanceKlass.cpp:1017 #8 0x1057a0260 in InstanceKlass::link_class(JavaThread*) instanceKlass.cpp:899 #9 0x10579ee04 in InstanceKlass::initialize_impl(JavaThread*) instanceKlass.cpp:1184 #10 0x10579ed50 in InstanceKlass::initialize(JavaThread*) instanceKlass.cpp:814 #11 0x1057d3c98 in InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) interpreterRuntime.cpp:219 #12 0x117bc8050 (<unknown module>) #13 0x117bb4150 (<unknown module>) #14 0x1057eae94 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415 #15 0x1057a2440 in InstanceKlass::call_class_initializer(JavaThread*) instanceKlass.cpp:1707 #16 0x10579f918 in InstanceKlass::initialize_impl(JavaThread*) instanceKlass.cpp:1316 #17 0x10579ed50 in InstanceKlass::initialize(JavaThread*) instanceKlass.cpp:814 #18 0x105b3df7c in LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*) linkResolver.cpp:1115 #19 0x105b41120 in LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*) linkResolver.cpp:1744 #20 0x105b41000 in LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*) linkResolver.cpp:1703 #21 0x1057d7280 in InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code) interpreterRuntime.cpp:819 #22 0x1057d830c in InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code) interpreterRuntime.cpp:998 #23 0x117bc6f00 (<unknown module>) #24 0x117bb881c (<unknown module>) #25 0x117bb881c (<unknown module>) #26 0x117bb881c (<unknown module>) #27 0x117bb8a8c (<unknown module>) #28 0x117bb8a8c (<unknown module>) #29 0x117bb8a8c (<unknown module>) #30 0x117bb881c (<unknown module>) #31 0x117bb881c (<unknown module>) #32 0x117bb881c (<unknown module>) #33 0x117bb8dbc (<unknown module>) #34 0x117bb881c (<unknown module>) #35 0x117bb902c (<unknown module>) #36 0x117bb8a8c (<unknown module>) #37 0x117bb4150 (<unknown module>) #38 0x1057eae94 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:415 #39 0x1057e99f0 in JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) javaCalls.cpp:179 #40 0x1057e9b1c in JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) javaCalls.cpp:185 #41 0x1059158c4 in thread_entry(JavaThread*, JavaThread*) jvm.cpp:2748 #42 0x105815414 in JavaThread::thread_main_inner() javaThread.cpp:772 #43 0x105814fd4 in JavaThread::run() javaThread.cpp:757 #44 0x1062110c0 in Thread::call_run() thread.cpp:224 #45 0x105d8fc88 in thread_native_entry(Thread*) os_bsd.cpp:597 #46 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #47 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
16-05-2025

[~asmehra] I am assigning this to you since you start looking on it already. Thank you.
15-05-2025

[~mbaesken] here is my proposed fix: https://github.com/openjdk/jdk/compare/master...ashu-mehra:jdk:JDK-8357047 Let me know if you can test it out.
15-05-2025

Yes, it is. I think it is complaining because AdapterFingerPrint::_value is declared to be an array of 3, but in reality it has more elements. And it is complaining when it tries to access elements beyond 3 in the constructor: AdapterFingerPrint(int total_args_passed, BasicType* sig_bt) { // Pack the BasicTypes with 8 per int _length = (total_args_passed + (_basic_types_per_int-1)) / _basic_types_per_int; int sig_index = 0; for (int index = 0; index < _length; index++) { int value = 0; for (int byte = 0; sig_index < total_args_passed && byte < _basic_types_per_int; byte++) { int bt = adapter_encoding(sig_bt[sig_index++]); assert((bt & _basic_type_mask) == bt, "must fit in 4 bits"); value = (value << _basic_type_bits) | bt; } _value[index] = value; <<< failing here } } [~mbaesken] I don't have a mac box to try the fix. Would you be able to test the fix if I give you the patch?
15-05-2025

Maybe it is related to JDK-8350209 ?
15-05-2025