Bug ID: JDK-8352112 [ubsan] hotspot/share/code/relocInfo.cpp:130:37: runtime error: applying non-zero offset 18446744073709551614 to null pointer

JDK-8352112 : [ubsan] hotspot/share/code/relocInfo.cpp:130:37: runtime error: applying non-zero offset 18446744073709551614 to null pointer

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 25

Priority: P4
Status: Resolved
Resolution: Fixed
OS: linux
CPU: generic

Submitted: 2025-03-16
Updated: 2025-03-21
Resolved: 2025-03-21

Versions (Unresolved/Resolved/Fixed)

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-8343789 - Move mutable nmethod data out of CodeCache
Relates :	JDK-8352426 - RelocIterator should correctly handle nullptr address of relocation data

Description

We see when running ubsan enabled binaries the following issue in a number of tests ; this came in most likely last week, was not seen before.
It is reported e.g. on Linux x86_64 :
e.g. in jtreg test serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java#default  (but also in a lot of other tests)

/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-linux_x86_64-opt/jdk/src/hotspot/share/code/relocInfo.cpp:130:37: runtime error: applying non-zero offset 18446744073709551614 to null pointer
    #0 0x7f214afdd731 in RelocIterator::initialize(nmethod*, unsigned char*, unsigned char*) src/hotspot/share/code/relocInfo.cpp:130
    #1 0x7f214ace0d5f in RelocIterator::RelocIterator(nmethod*, unsigned char*, unsigned char*) src/hotspot/share/code/relocInfo.hpp:1442
    #2 0x7f214ace0d5f in nmethod::fix_oop_relocations(unsigned char*, unsigned char*, bool) src/hotspot/share/code/nmethod.cpp:1768
    #3 0x7f214acfa3fc in OopRecorder::copy_values_to(nmethod*) src/hotspot/share/code/oopRecorder.hpp:231
    #4 0x7f214acfa3fc in CodeBuffer::copy_values_to(nmethod*) src/hotspot/share/asm/codeBuffer.hpp:718
    #5 0x7f214acfa3fc in nmethod::nmethod(Method*, CompilerType, int, int, CodeOffsets*, CodeBuffer*, int, ByteSize, ByteSize, OopMapSet*, int) src/hotspot/share/code/nmethod.cpp:1344
    #6 0x7f214acfabef in nmethod::new_native_nmethod(methodHandle const&, int, CodeBuffer*, int, int, int, ByteSize, ByteSize, OopMapSet*, int) src/hotspot/share/code/nmethod.cpp:1118
    #7 0x7f214b0c8643 in SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle const&, int, BasicType*, VMRegPair*, BasicType) src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp:1874
    #8 0x7f214b098ea4 in AdapterHandlerLibrary::create_native_wrapper(methodHandle const&) src/hotspot/share/runtime/sharedRuntime.cpp:2846
    #9 0x7f214b2eb57e in SystemDictionary::find_method_handle_intrinsic(vmIntrinsicID, Symbol*, JavaThread*) src/hotspot/share/classfile/systemDictionary.cpp:1985
    #10 0x7f214a939a0d in LinkResolver::lookup_polymorphic_method(LinkInfo const&, Handle*, JavaThread*) src/hotspot/share/interpreter/linkResolver.cpp:477
    #11 0x7f214a93fc69 in LinkResolver::resolve_method(LinkInfo const&, Bytecodes::Code, JavaThread*) src/hotspot/share/interpreter/linkResolver.cpp:787
    #12 0x7f214a944a10 in LinkResolver::linktime_resolve_static_method(LinkInfo const&, JavaThread*) src/hotspot/share/interpreter/linkResolver.cpp:1135
    #13 0x7f214a944f37 in LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*) src/hotspot/share/interpreter/linkResolver.cpp:1108
    #14 0x7f214ac6a242 in MethodHandles::resolve_MemberName(Handle, Klass*, int, bool, JavaThread*) src/hotspot/share/prims/methodHandles.cpp:773
    #15 0x7f214ac6ac7a in MHN_resolve_Mem src/hotspot/share/prims/methodHandles.cpp:1116

Comments

Changeset: 22182f71 Branch: master Author: Vladimir Kozlov <kvn@openjdk.org> Date: 2025-03-21 20:51:30 +0000 URL: https://git.openjdk.org/jdk/commit/22182f71ed520150b1ee05e5b788ecddfb0a6508
21-03-2025
> I closed first PR because missed bug id in commit message You don't need the bug id in the commit message, the bot will squash all the commits anyway before integration. You can just adjust the PR title directly, if the bug id is missing.
19-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24102 Date: 2025-03-18 18:35:06 +0000
18-03-2025
I closed first PR because missed bug id in commit message. I tried to fix it and screwed up git history :(
18-03-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24100 Date: 2025-03-18 18:01:58 +0000
18-03-2025
I reproduced failure with fastdebug VM on linux-x64 running next tests pointer by Matthias: ava/io/Console/ConsolePromptTest.java sun/security/pkcs12/ImportPassKeyAlg.java With the fix they passed.
18-03-2025
Thank you, [~mbaesken], for confirming the fix.
18-03-2025
> can you test 8352112.patch I attached? Hi [~kvn] the patch seems to work, at least in the mentioned tests serviceability/jvmti/vthread/GetThreadState and java/io/Console the issue is gone when your patch 8352112.patch is applied.
18-03-2025
> I was not able to reproduce failure with fast debug VM built with --enable-ubsan running serviceability/jvmti tests on linux-x64 I saw the issues on Linux x86_64 / Linux aarch64 (both gcc13.2.0 devkit used) / macOS aarc64 (XCode 15) , testing runs with opt builds (I would guess it shows also with (fast)debug but haven't checked so far) . The issue was seen in a lot of tests (I think about 100+), also java/io/Console/ConsolePromptTest.java sun/security/pkcs12/ImportPassKeyAlg.java Tests were run with higher concurrency, e.g. java -Xms256m -Xmx512m -vmoption:-Xmx768m -avm -conc:8 :tier2 not sure if this makes a difference.
18-03-2025
ILW = Undefined behavior in relocation code (regression - never observed), found with sanitizer - never observed, no workaround = MLH = P4
18-03-2025
Ouch! This issue is definitely related to my change JDK-8343789. The problem occurs in RelocIterator::initialize, where it subtracts 1 from nm->relocation_begin(). If relocation_begin() returns nullptr, this results in undefined behavior, as the C++ Standard prohibits pointer arithmetic on nullptr. To resolve this I see two possible approaches: 1) Use a legal pointer, as Vladimir suggests. This avoids undefined behavior by ensuring _current is always initialized to a valid address. 2) Introduce an additional check before performing pointer arithmetic: ---------------------------------------------------------------------------------------- diff --git a/src/hotspot/share/code/relocInfo.cpp b/src/hotspot/share/code/relocInfo.cpp index 7aae32759dd..06a79b93074 100644 --- a/src/hotspot/share/code/relocInfo.cpp +++ b/src/hotspot/share/code/relocInfo.cpp @@ -127,7 +127,10 @@ void RelocIterator::initialize(nmethod* nm, address begin, address limit) { guarantee(nm != nullptr, "must be able to deduce nmethod from other arguments"); _code = nm; - _current = nm->relocation_begin() - 1; + _current = nm->relocation_begin(); + if (_current != nullptr) { + _current--; + } _end = nm->relocation_end(); _addr = nm->content_begin(); diff --git a/src/hotspot/share/code/relocInfo.hpp b/src/hotspot/share/code/relocInfo.hpp index 25cca49e50b..0c45274e02a 100644 --- a/src/hotspot/share/code/relocInfo.hpp +++ b/src/hotspot/share/code/relocInfo.hpp @@ -603,7 +603,9 @@ class RelocIterator : public StackObj { // get next reloc info, return !eos bool next() { - _current++; + if (_current != nullptr) { + _current++; + } assert(_current <= _end, "must not overrun relocInfo"); if (_current == _end) { set_has_current(false); ---------------------------------------------------------------------------------------- I think the first approach (using a legal pointer) is simpler and cleaner.
18-03-2025
I installed libubsan-8.5.0-24.0.1.el8_10.x86_64 for this.
17-03-2025
I was not able to reproduce failure with fast debug VM built with --enable-ubsan running serviceability/jvmti tests on linux-x64
17-03-2025
[~mbaesken] would be nice to know flags you used for jtreg testing. And also failed tests which does not require nativepath test libraries.
17-03-2025
[~mbaesken] can you test 8352112.patch I attached?
17-03-2025
Before JDK-8343789 relocation_begin() was never null even if there was no relocations - it pointed to beginning of code. With that fix relocation_begin() points to _mutable_data address which could be nullptr if there is no relocation and metadata. There easy fix is to not have nullptr in _mutable_data. We could do that similar to what we do for _immutable_data: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.cpp#L1514
17-03-2025
[~bulasevich] please look.
17-03-2025
Probably a regression from JDK-8343789.
17-03-2025
Issue came in between 8th and 15th March; [~shade], [~aivanov] could you maybe have a look, maybe it is related to recent hotspot/share/code changes ?
16-03-2025