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