RFR: 8364198: NMT should have a better corruption message
Vladimir Kozlov
kvn at openjdk.org
Tue Jul 29 16:09:00 UTC 2025
On Tue, 29 Jul 2025 08:36:59 GMT, Johan Sjölen <jsjolen at openjdk.org> wrote:
>> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
>>
>>
>> *** glibc detected *** malloc(): memory corruption
>>
>>
>> Something like below would do, I think.
>>
>>
>> NMT detected memory corruption. Block at ...
>>
>>
>> ...or even:
>>
>>
>> Memory corruption detected. Block at ...
>
>> Makes sense. I am not sure about the "bug" part. Also, do we care about mentioning NMT at all? I think a useful template is GCC malloc:
>>
>> ```
>> *** glibc detected *** malloc(): memory corruption
>> ```
>>
>> Something like below would do, I think.
>>
>> ```
>> NMT detected memory corruption. Block at ...
>> ```
>>
>> ...or even:
>>
>> ```
>> Memory corruption detected. Block at ...
>> ```
>
> I wrote it like this to really hammer home the point, I felt it was more unambiguous.
>
> I'm integrating it as-is, thank you all for your comments.
>
> @vnkozlov, it's unfortunately hard to add more info as the header (that which is 'corrupted') is also where we store what kind of allocation it is.
>> @jdksjolen is it possible to give more information in output? For example, where address is located: metaspace, code cache, arena, some C heap allocations (Does NMT keep track of such?).
> Note that we already print out hexdump and whatnot for the broken block.
I did not know that. But looking on log in [JDK-8361382](https://bugs.openjdk.org/browse/JDK-8361382) I see it now.
Should we include this into hs_err file instead as we do for code crash?
Is it possible to collect and provide information for the block preceding current block when it's header is damaged?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26507#issuecomment-3133171659
More information about the hotspot-runtime-dev
mailing list