RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5]

[Afshin Zafari]

On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN.
>> The acceptable value is changed to 64K.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uintptr_t -> uint64_t

I used `uintptr_t` for addresses, but there are pre-existing uses of `uint64_t` in the code that are used for addresses:

#define SIZE_64K  ((uint64_t) UCONST64(      0x10000))
#define SIZE_256M ((uint64_t) UCONST64(   0x10000000))
#define SIZE_32G  ((uint64_t) UCONST64(  0x800000000))

// Helper for heap allocation. Returns an array with addresses
// (OS-specific) which are suited for disjoint base mode. Array is
// null terminated.
static char** get_attach_addresses_for_disjoint_mode() {
  static uint64_t addresses[] = {```

> f anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset).
> 
> That part I think would read much better by checking for the underflow first:
> 
> ```c++
>       uintptr_t lowest_start = aligned_heap_base_min_address;
>       if (size <= UnscaledOopHeapMax) {
>         lowest_start = MAX2<uintptr_t>(lowest_start, UnscaledOopHeapMax - size);
>       }
>       lowest_start = align_up(lowest_start, attach_point_alignment);
> ```

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306322492
PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306327411