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

[Johan Sjölen]

On Wed, 19 Mar 2025 17:52:46 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.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update field default setting

I suspect that this change fixes the UBSAN issue but instead causes a runtime issue which NMT detects, see this bug: https://bugs.openjdk.org/browse/JDK-8361382

I added a caused-by link, but I'm not 100% sure that this is the case yet.

src/hotspot/share/code/codeBlob.cpp line 156:

> 154:   } else {
> 155:     // We need unique and valid not null address
> 156:     assert(_mutable_data = blob_end(), "sanity");

Did this mean to assign the `_mutable_data`? I think it should be `==`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24102#pullrequestreview-3061046981
PR Review Comment: https://git.openjdk.org/jdk/pull/24102#discussion_r2235188508