RFR: JDK-8295865: Several issues with os::realloc

[Thomas Stuefe]

On Mon, 31 Oct 2022 09:39:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are several issues with os::realloc():
>> 
>> 1) If realloc(3) fails, the original block will be left untouched. That is fine, and the caller may expect this and continue to use the old block, including handing it to os::free() later. But NMT has marked the original block as dead already, and subsequent os::free() or os::realloc() will trigger a false fatal block integrity error. Therefore, if realloc(3) fails, we need to revive the NMT header and re-account the original block before returning.
>> 
>> 2) If handed in very large sizes, the size may overflow if the NMT header is added. The result would be that the VM reallocates to a much smaller buffer which would cause subsequent memory corruption if the caller were to use the buffer (same as JDK-8286519, but for realloc).
>> 
>> 3) If os::realloc() enlarges a buffer, the newly added memory should be zapped with uinitBlockPad as we do for os::malloc(). Of course we only can do this if NMT is enabled, otherwise we won't know the original block size.
>> 
>> ------------------------------
>> 
>> The patch fixes all three issues and adds hopefully thorough enough regression gtests for them. Remember that these gtests will run, as part of the jtreg gtest runners, in all NMT modes.
>> 
>> The largest diff hunk is inside os::realloc(). Note that I separated the two cases NMT=summary/detail and NMT=off, since it makes the coding easier to understand and we also run less code in the standard case of NMT==off.
>
> test/hotspot/gtest/testutils.hpp line 57:
> 
>> 55: #define ASSERT_NULL(p)      ASSERT_EQ(p2i(p), 0)
>> 56: #define EXPECT_NOT_NULL(p)  EXPECT_NE(p2i(p), 0)
>> 57: #define EXPECT_NULL(p)      EXPECT_EQ(p2i(p), 0)
> 
> These aren't "convenience asserts" - should they be somewhere else? What does EXPECT_NULL actually do?

They extend the existing `ASSERT_xxx` and `EXPECT_xxx` macros we get from gtest (in gtest.h). I cannot add them to gtest, of course, they have to live within our gtest wrapper code. This is as good a place as any IMO. Note we do similar things with other test helpers, e.g. threadHelper.inline.hpp.

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

PR: https://git.openjdk.org/jdk/pull/10857