JDK-8360942 : [ubsan] aotCache tests trigger runtime error: applying non-zero offset 16 to null pointer in CodeBlob::relocation_end()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2025-06-28
  • Updated: 2025-07-07
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 26
26Unresolved
Related Reports
Causes :  
JDK-8350209 - Preserve adapters in AOT cache
Description
When running with ubsan-enabled opt binaries on macOS aarch64, some cds aot tests like

runtime/cds/appcds/aotCache/HelloAOTCache
runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest
runtime/cds/appcds/aotCode/AOTCodeFlags

trigger this issue; this was not observed on so far Linux.

 stderr: [/jdk/src/hotspot/share/code/codeBlob.hpp:235:97: runtime error: applying non-zero offset 16 to null pointer
    #0 0x104c2d798 in CodeBlob::relocation_end() const codeBlob.hpp:235
    #1 0x104c29bf8 in CodeBlob::relocation_size() const codeBlob.hpp:250
    #2 0x104c2a9b4 in AOTCodeReader::compile_code_blob(char const*, int, int*) aotCodeCache.cpp:950
    #3 0x104c2a5e4 in AOTCodeCache::load_code_blob(AOTCodeEntry::Kind, unsigned int, char const*, int, int*) aotCodeCache.cpp:922
    #4 0x105cc9928 in AdapterHandlerLibrary::lookup_aot_cache(AdapterHandlerEntry*) sharedRuntime.cpp:2772
    #5 0x105cca690 in AdapterHandlerEntry::link() sharedRuntime.cpp:2968
    #6 0x105cc8cfc in AdapterHandlerLibrary::link_aot_adapters() sharedRuntime.cpp:2995
    #7 0x105cc248c in AdapterHandlerLibrary::initialize() sharedRuntime.cpp:2573
    #8 0x1055527c0 in init_globals() init.cpp:165
    #9 0x105ffc1b4 in Threads::create_vm(JavaVMInitArgs*, bool*) threads.cpp:592
    #10 0x10569dc94 in JNI_CreateJavaVM jni.cpp:3680
    #11 0x1009464d0 in JavaMain java.c:494
    #12 0x10094d4fc in ThreadJavaMain java_md_macosx.m:679
    #13 0x197372f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
    #14 0x19736dd30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26175 Date: 2025-07-07 23:48:03 +0000
07-07-2025
> I surprise that ubsan does not report the same issue for x86. The code is the same - it is not CPU specific. And the path in shown call stack is always executed. Hi [~kvn] Vladimir , from my gcc/ubsan vs. clang/ubsan experience, clang/ubsan reports a little bit more issues than gcc/ubsan . Maybe the checks differ a little bit from one to the other.
04-07-2025
I surprise that ubsan does not report the same issue for x86. The code is the same - it is not CPU specific. And the path in shown call stack is always executed.
03-07-2025
We want to backport it into JDK 25 to avoid ubsan failure for it. CodeBlob::relocation_size() is calculated as (_mutable_data + _relocation_size - _mutable_data). relocation_size() could be called from AOT code loading before we allocate mutable data (the size is used to find how big space should be allocated for it). So the expression at that point is (NULL + _relocation_size - NULL) which returns correct result. But we should just return _relocation_size which is recorded anyway in AOT data.
03-07-2025
ILW = Potential undefined behavior, with ubsan and AOT, no workaround but disable AOT = MLH = P4 Targeting this to JDK 26 for now but depending on the severity of this, we should consider raising priority and backporting to JDK 25.
02-07-2025
I think that code comes from JDK-8350209. [~kvn], could you please have a look?
02-07-2025