RFR: 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]' [v2]

Kim Barrett kbarrett at openjdk.org
Thu Jun 13 13:06:15 UTC 2024


On Tue, 11 Jun 2024 08:57:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The implementation in `BufferNode` looks like the pattern which I'm fixing, here. The length is specified, but we're accessing the array beyond it and this is what UBSan is complaining about. The idea here is to avoid specifying the length and using a plain address computation instead. UBSan seems to be happy with it. Do you still see UB involved, here?

They are different.

- The current code takes the address of the array member and uses that as the
base of an array access. So it's effectively doing obj._buffer[i] for i > 0.
And that is UB, and ubsan rightly complains.

- The BufferNode approach uses the array member to get the compiler-calculated
offset from the object base to the start of the pseudo-VLA. It then does an
address calculation with the containing object and that offset to get the
address of the start of the buffer.

This approach was recently used to fix an identical ubsan issue:
https://bugs.openjdk.org/browse/JDK-8332683
G1: G1CardSetArray::EntryDataType [2] triggers ubsan runtime errors

- The approach currently in the PR does some fragile ad hoc calculation to get
the address of the start of the buffer.  There's also no indication that we're
simulating a VLA here.

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

PR Comment: https://git.openjdk.org/jdk/pull/19623#issuecomment-2165610625


More information about the hotspot-runtime-dev mailing list