RFR: 8372988: Test runtime/Nestmates/membership/TestNestHostErrorWithMultiThread.java failed: Unexpected interrupt
David Holmes
dholmes at openjdk.org
Mon Dec 15 20:15:59 UTC 2025
On Mon, 15 Dec 2025 14:36:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> In the fix for JDK-8365526 we changed the `set_nest_host_error` code so that we would overwrite the message in the resolution error table, and free the previous copy of the message (the messages will always be the same). This was the wrong thing to do as the message could be in-use at the time it was freed, leading to either a missing message, or an assertion failure when we checked the messages for UTF8 validity.
>>
>> The fix is to simply only ever set the message once (freeing it only when the entry is removed from the table).
>>
>> Testing:
>> - TestNestHostErrorWithMultiThread.java with an augmented VM that inserts a delay that helped trigger the bug
>> - tiers 1-3 sanity
>>
>> Thanks
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1883:
>
>> 1881: else {
>> 1882: assert(strcmp(nhe, message) == 0, "New message %s, differs from original %s", message, nhe);
>> 1883: }
>
> The caller allocates this message so the caller should free it but that would require passing up that we actually installed the message. We could keep this leak temporarily until https://bugs.openjdk.org/browse/JDK-8372373 is fixed to resource allocate the message. Or add a FREE_C_HEAP_ARRAY here even though it's not the best place for it?
Hmmm. We can't resource allocate the message unless we then copy to the C-heap as it has to out-live the thread that creates it. But we can pass the stringStream instead of the exposed "char*" and so avoid the leak.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28817#discussion_r2620696756
More information about the hotspot-runtime-dev
mailing list