JDK-8357047 : [ubsan] AdapterFingerPrint::AdapterFingerPrint runtime error: index 3 out of bounds
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2025-05-15
  • Updated: 2025-05-30
  • Resolved: 2025-05-30
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 masterFixed
Related Reports
Causes :  
JDK-8350209 - Preserve adapters in AOT cache
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
Changeset: b7ca672d Branch: master Author: Ashutosh Mehra <asmehra@openjdk.org> Date: 2025-05-30 18:26:19 +0000 URL: https://git.openjdk.org/jdk/commit/b7ca672d5c5f11f472110154868f08299f6e8796
30-05-2025
[~mbaesken] > I built with your patch and run java/awt/image/BufferedImage/TinyScale.java (the test triggering for example the issue reported) and the issue is gone ! Thanks for confirming.
26-05-2025
> can you please try out the new patch from the PR https://git.openjdk.org/jdk/pull/25378 and confirm if the ubsan issue is fixed. Sorry, I have no means to try it myself. Hi [~asmehra] I built with your patch and run java/awt/image/BufferedImage/TinyScale.java (the test triggering for example the issue reported) and the issue is gone !
23-05-2025
[~mbaesken] can you please try out the new patch from the PR https://git.openjdk.org/jdk/pull/25378 and confirm if the ubsan issue is fixed. Sorry, I have no means to try it myself.
22-05-2025
HI [~asmehra] > undefined symbol: __ubsan_handle_type_mismatch_v1 Too bad, seems there is still an issue with ubsan on Linux when clang is used, also on aarch64 (I think I had a JBS bug for this for Linux x86_64). > I am able to build with gcc on x86/linux. Is this issue specific to clang and aarch64? If it occurs with gcc as well, how do you run the test to reproduce this issue? I did not see this issue reported with gcc when using ubsan; not sure why it should be there also with the other compiler but maybe the ubsan implementation is slightly different there.
22-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25378 Date: 2025-05-22 02:46:37 +0000
22-05-2025
[~kvn] > We are observing memory stomps in our AOT testing and I am looking through or AOT code to find what is causing it. It may sound from the issue that the code is accessing invalid memory. However, I feel this is the case of ubsan reporting "false" positive. AdapterFingerPrint::_value is declared to be a fixed size (=3) array, but this size is valid only if the number of args are less than 24( =3*sizeof(int)*_basic_types_per_int). When the number of args > 24 then length of the _value array can be more than 3, which means the 0-based index used to access _value can be more than 2 and this is flagged by ubsan. But I agree with you that we can get rid of compact vs long, and just declare _value as int*. This will simplify the implementation and keep the ubsan quiet. Thanks for pointing it out. I will work on this change.
21-05-2025
We are observing memory stomps in our AOT testing and I am looking through or AOT code to find what is causing it.
21-05-2025
Or we can return to original implementation with fixed AdapterFingerPrint size and CHEAP array if needed. I don't think it will complicate AOT caching of it.
21-05-2025
[~asmehra] I looked on implementation and I would suggest to remove notion of compact vs long. Declare AdapterFingerPrint::_value as (int *) and assign it to align_up((int*)((address)this + sizeof(AdapterFingerPrint)), int). You already allocate space for AdapterFingerPrint based on arguments count. Consider recording total size in debug VM to check that you don't access beyond.
21-05-2025
[~mbaesken] I tried to build with clang using ubsan on x86/linux and aarch64/linux but hitting the same issue on both systems during build: Error: dl failure on line 532 Error: failed /root/work/jdk/build/base-fd/jdk/lib/server/libjvm.so, because /root/work/jdk/build/base-fd/jdk/lib/server/libjvm.so: undefined symbol: __ubsan_handle_type_mismatch_v1 gmake[3]: *** [modules/jdk.compiler/Gendata.gmk:60: /root/work/jdk/build/base-fd/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 6 I am able to build with gcc on x86/linux. Is this issue specific to clang and aarch64? If it occurs with gcc as well, how do you run the test to reproduce this issue?
21-05-2025
ILW = Array out of bounds error (false positive), single test with ubsan, no workaround but disable adapter sharing = MLH = P4
21-05-2025
> 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). [~ihse] , [~erikj] should I open a JBS issue for this ? Or is it too much overhead , considering that '--enable-ubsan' is a special flag and only some OpenJDK developers will use it ?
20-05-2025
> 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