RFR: 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset 18446744073709551614 to null pointer [v2]

Stefan Karlsson stefank at openjdk.org
Thu May 30 15:46:16 UTC 2024


On Thu, 30 May 2024 12:38:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We're not hiding a warning. Using pointer addition with `nullptr` or result `nullptr` is undefined behavior. So, the current implementation is not guaranteed to do what we expect. It only works because compilers seem to be merciful.

I think you are reading too much into the words I used. Ubsan is warning/complaining/error that the code is problematic.

> However, casting `nullptr` to `uintptr_t` is guaranteed to be 0. So, switching to unsigned integer arithmetics avoids this problem.

I fully understand the suggested patch.

> The `RelocIterator` code is designed to work with such values.

This is the crux of my complaint. Is this a good design given that the usage of null isn't apparent on first read? Or was this only something that grew into existence after a while? And would it make more sense for maintainability to not be doing this? I think it is important to think about those questions when trying to handle all these ubsan failures.

FWIW, I (and Axel) took a step back and asked why do we think it is necessary to support null pointers here and I think you can see the musing around in Axel's response above.

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

PR Comment: https://git.openjdk.org/jdk/pull/19424#issuecomment-2139999240


More information about the hotspot-compiler-dev mailing list