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