RFR: 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]' [v2]
Martin Doerr
mdoerr at openjdk.org
Fri Jun 14 17:23:15 UTC 2024
On Thu, 13 Jun 2024 13:03:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 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.
Got it, thanks! I had missed that BufferNode uses and address computation instead of array member access. So, it's basically the same trick as I was using.
> 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.
I've updated my implementation to use `_cloned_vtable[1]` again with an address computation. Please note that we're calling it "Pseudo flexible array member", not VLA. I had also described it as "flexible array member" emulation in my previous version.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19623#issuecomment-2168458016
More information about the hotspot-runtime-dev
mailing list