RFR: 8360941: [ubsan] MemRegion::end() shows runtime error: applying non-zero offset 8388608 to null pointer [v6]
Kim Barrett
kbarrett at openjdk.org
Mon Jul 21 21:36:29 UTC 2025
On Mon, 21 Jul 2025 13:48:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>> When running HS test
>> gtest/GTestWrapper.java
>> with ubsan-enabled binaries on macOS aarch64, the following error is reported (did not see this so far on Linux but there we use gcc and it seems the gcc/ubsan checks are a bit more limited).
>>
>> test/hotspot/gtest/gc/g1/test_freeRegionList.cpp:37: Failure
>> Death test: child_G1FreeRegionList_length_()
>> Result: died but not with expected exit code:
>> Terminated by signal 6 (core dumped)
>> Actual msg:
>>
>> [ DEATH ] /jdk/src/hotspot/share/memory/memRegion.hpp:66:43: runtime error: applying non-zero offset 8388608 to null pointer
>> [ DEATH ] #0 0x108afd6f4 in MemRegion::end() const+0x84 (libjvm.dylib:arm64+0x16556f4)
>> [ DEATH ] #1 0x1075c68a0 in G1FreeRegionList_length_other_vm_Test::TestBody()+0x380 (libjvm.dylib:arm64+0x11e8a0)
>> [ DEATH ] #2 0x1090f3bb0 in testing::Test::Run()+0xc0 (libjvm.dylib:arm64+0x1c4bbb0)
>> [ DEATH ] #3 0x1090f4d94 in testing::TestInfo::Run()+0x1e4 (libjvm.dylib:arm64+0x1c4cd94)
>> [ DEATH ] #4 0x1090f6754 in testing::TestSuite::Run()+0x43c (libjvm.dylib:arm64+0x1c4e754)
>> [ DEATH ] #5 0x109103ca0 in testing::internal::UnitTestImpl::RunAllTests()+0x48c (libjvm.dylib:arm64+0x1c5bca0)
>> [ DEATH ] #6 0x109103588 in testing::UnitTest::Run()+0x78 (libjvm.dylib:arm64+0x1c5b588)
>> [ DEATH ] #7 0x1074a9ac0 in runUnitTestsInner(int, char**)+0x724 (libjvm.dylib:arm64+0x1ac0)
>> [ DEATH ] #8 0x102dc3f18 in main+0x2c (gtestLauncher:arm64+0x100003f18)
>> [ DEATH ] #9 0x196fea0dc (<unknown module>)
>> [ DEATH ]
>> [ DEATH ] SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /jdk/src/hotspot/share/memory/memRegion.hpp:66:43 in
>> [ DEATH ]
>>
>>
>>
>> Seems the test_freeRegionList.cpp uses a special MemRegion starting at nullptr ; but this causes a bit of trouble when adding to start == nullptr .
>> So far I see this issue just in the gtest, seems other MemRegion objects do not start at nullptr .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>
> Suggestion by Thomas Stuefe
Changes requested by kbarrett (Reviewer).
test/hotspot/gtest/gc/g1/test_freeRegionList.cpp line 50:
> 48: const size_t sz = szw * BytesPerWord;
> 49: char* addr = os::reserve_memory(sz, mtTest);
> 50: MemRegion heap((HeapWord*)addr, szw);
So far as I can tell, there's no guarantee that `os::reserve_memory` will return an address with any
particular alignment. Since the earlier attempt with unaligned storage failed, it may only be by accident
that this isn't failing as well. We have `os::reserve_memory_aligned`, or could add an extra region to
the desired size and align up the result.
-------------
PR Review: https://git.openjdk.org/jdk/pull/26216#pullrequestreview-3039929835
PR Review Comment: https://git.openjdk.org/jdk/pull/26216#discussion_r2220399489
More information about the hotspot-runtime-dev
mailing list