RFR: 8352112: [ubsan] hotspot/share/code/relocInfo.cpp:130:37: runtime error: applying non-zero offset 18446744073709551614 to null pointer [v2]

[Vladimir Kozlov]

On Wed, 30 Jul 2025 09:03:29 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:

>> Yes, it was fixed. And they were harmless.
>> 
>> I think @jdksjolen linked it because of call stack. But I also don't know how it could cause NMT bug.
>> @jdksjolen did you try to to undo these changes and reproduce https://bugs.openjdk.org/browse/JDK-8361382 ?
>> 
>> 
>> V [libjvm.dylib+0xbf1c8c] VMError::report(outputStream*, bool)+0xa9c (mallocHeader.inline.hpp:107)
>> V [libjvm.dylib+0xbf5d25] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x575
>> V [libjvm.dylib+0x404e20] DebuggingContext::~DebuggingContext()+0x0
>> V [libjvm.dylib+0x8f770f] MallocHeader* MallocHeader::resolve_checked_impl<void*, MallocHeader*>(void*)+0x15f
>> V [libjvm.dylib+0x8f720c] MallocTracker::record_free_block(void*)+0xc
>> V [libjvm.dylib+0x9a719a] os::free(void*)+0xea
>> V [libjvm.dylib+0x388fb4] CodeBlob::purge()+0x44
>> V [libjvm.dylib+0x978e98] nmethod::purge(bool)+0x308
>> V [libjvm.dylib+0x380439] ClassUnloadingContext::purge_nmethods()+0x69
>
> My reasoning was based on the fact that what used to be set to a constant, `nullptr`, is no longer set to a constant. I'm saying that `blob_end()` isn't a constant, because it can be changed with `adjust_size()`, but I think that @vnkozlov said that that's unlikely, as it's only changed for interpreter stubs and not nmethods. The only other possibility is that `nmethod`s are copied, so their `this` pointer changes, this will make `blob_end()` change, and this may incur a double free. This double free is detected by NMT, which leads to the crash.
> 
> I think it may still be best to 'fix' this by setting the `_mutable_data` to `nullptr` again and fixing the iterators, as it does simplify reasoning around this (and imho, understanding the code).

We do not copy nmethods. At least until #23573 is integrated - and it will be under flag.

`_mutable_data` field is initialized during final method installation into CodeCache - nothing modifies it for nmethods.

I can add debug flag to CodeBlob to catch double free. But as I commented in [JDK-8361382](https://bugs.openjdk.org/browse/JDK-8361382) it is most likely the issue is a buffer overflow from preceding memory block which stomped over header.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24102#discussion_r2243145779