RFR: 8331953: ubsan: metaspaceShared.cpp:1305:57: runtime error: applying non-zero offset 12849152 to null pointer

[Matthias Baesken]

On Thu, 9 May 2024 06:28:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Reported by @MBaesken at SAP. ubsan complains about this line:
> 
> 
> const size_t ccs_begin_offset = align_up(base_address + archive_space_size,
>                                            class_space_alignment) - base_address;
> 
> 
> `base_address` here is the wish address, with NULL being an explicitly allowed value that indicates "no preference". The line calculates the offset of the class space within the future combined CDS+class-space mapping. Ubsan complains about `base_address` being possibly NULL.
> 
> Ubsan is missing the point somewhat. The addition is not a problem, on our platforms at least.
> 
> However, it highlights a slight incorrectness (which it did not notice): `base_address` is the wish for the future base of the Klass range. That wish is not guaranteed to be fulfilled; the eventual start of the Klass range could be somewhere else. Therefore, calculating the class space offset with an alignment based on that wish address is wrong. It always worked in practice since `base_address` was always aligned to class_space_alignment (16MB).
> 
> Hence, the fix is simple: We just make the alignment requirement for the base address explicit. When running with class space, we now assert that `base_address` is aligned to  class space alignment (as well as CDS core region alignment, but that is much smaller). Since `base_address` is calculated either from a hard-wired default or from the `SharedBaseAddress` user input, and both are ensured to be properly aligned, that assert should never fire.
> 
> Then, the offending calculation can be simplified by removing the base address from it.

I added the PR to our build+test queue .

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

PR Comment: https://git.openjdk.org/jdk/pull/19152#issuecomment-2104037045