RFR: 8352112: [ubsan] hotspot/share/code/relocInfo.cpp:130:37: runtime error: applying non-zero offset 18446744073709551614 to null pointer
Dean Long
dlong at openjdk.org
Wed Mar 19 00:06:08 UTC 2025
On Tue, 18 Mar 2025 18:35:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> Before [JDK-8343789](https://bugs.openjdk.org/browse/JDK-8343789) `relocation_begin()` was never null even when there was no relocations - it pointed to the beginning of constant or code section in such case. It was used by relocation code to simplify code and avoid null checks.
> With that fix `relocation_begin()` points to address in `CodeBlob::_mutable_data` field which could be `nullptr` if there is no relocation and metadata.
>
> There easy fix is to avoid `nullptr` in `CodeBlob::_mutable_data`. We could do that similar to what we do for `nmethod::_immutable_data`: [nmethod.cpp#L1514](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.cpp#L1514).
>
> Tested tier1-4, stress, xcomp. Verified with failed tests listed in bug report.
src/hotspot/share/code/codeBlob.cpp line 156:
> 154: } else {
> 155: // We need unique and valid not null address
> 156: _mutable_data = blob_end();
It makes me a little nervous pointing this value to real data. When RelocIterator computes `_current = nm->relocation_begin() - 1`, it should never read or write from that address, but how can we guarantee that? Any non-null address that is guarateed unmapped would do, or a special protetected page like `bad_page` here: https://github.com/openjdk/jdk/blob/8e530633a9d99d7ce585cafd5573cb89212feee7/src/hotspot/share/runtime/safepointMechanism.cpp#L66. If using protected memory seems like overkill, then I suggest using a static. Something like this:
static union {
relocInfo _dummy[1];
} _empty[2];
[...]
_mutable_data = _empty+1;
However, I think this is not the first time we have run into this issue with RelocIterator. Maybe it's time that we rewrote it to avoid this situation?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24102#discussion_r2002179287
More information about the hotspot-compiler-dev
mailing list