RFR: 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset 18446744073709551614 to null pointer [v3]
Stefan Karlsson
stefank at openjdk.org
Fri May 31 15:43:02 UTC 2024
On Fri, 31 May 2024 11:37:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> I guess Matthias only wanted to fix UB in hotspot ASAP and doesn't have the bandwidth to change the design everywhere.
The proposal solves the UB but (IMHO) adds a wart to the code instead of taking a small step back and fixing the root cause of the UB. This then leaves the wart for other maintainers fix with their own bandwidth.
> Sounds like you guys already have an alternative solution which already works. Maybe you would like to put it into a PR and we continue the discussion there?
I would prefer if we did the right fix here in this PR.
> Nevertheless, having sub / add_to_ptr_maybe_null available in hotspot may be a good thing. There are some places where we really use additions with nullptr (e.g. index_oop_from_field_offset_long in unsafe.cpp).
My previous arguments have been that I don't think it is a good thing, so our opinion here differs.
How many places are there that really *should* be doing add/sub with nullptr? Are most places just like this PR, where using `add_to_ptr_maybe_null` is a convenient way to get away from the UB, but the "real" fix would be to remove the null pointer? Given that we have different opinions about this, could we at least wait with adding `add_to_ptr_maybe_null` until we have assessed the other instances of this UB issue? Do you have a list of other places that have this issue?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19424#issuecomment-2142523001
More information about the hotspot-compiler-dev
mailing list