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

[Thomas Stuefe]

On Wed, 15 May 2024 17:24:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > We see now errors like this on Linux ppc64le with the patch added.
> > ```
> > #  Internal Error (/jdk/src/hotspot/share/cds/metaspaceShared.cpp:1295), pid=7002, tid=7006
> > #  assert(is_aligned(base_address, base_address_alignment)) failed: 
> >    Archive base address unaligned: 0x0000000000010000, needs alignment: 16777216.
> > ```
> 
> This looks curious. Why would `base_address` be `0x0000000000010000`? Is that value contained in `static_mapinfo->requested_base_address()`? I am wondering is there's a rounding/alignment bug that leads up to this value on ppc64le.

No, that's the test. It dumps archives with different SharedBaseAddress, then checks that the archives can be loaded. One of the SharedBaseAddress values is 64K:

https://github.com/openjdk/jdk/blob/95f79c678737fb8de9ed45c516761d4d818869ef/test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java#L76

It used to work before this patch, though subtly broken, because we did not require the archive base to be aligned to class space alignment. Instead, we aligned the class space within the mapping (so, gap between archive and class space can be higher). That, however, has the problem described in the description. We calculate the class space offset in the mapping *before* actually mapping, based on the SharedAddressBase given at archive creation. If the mapping fails (likely with a value aligned to 64K) and the real mapping later is aligned at a different alignment (likely with 64K), either class space start will be misaligned or it gets re-aligned but then the mapping size may be too small.

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

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