RFR: JDK-8298003: NMT: fatal block printout does not show the correct corruption address
Thomas Stuefe
stuefe at openjdk.org
Fri Dec 2 08:52:32 UTC 2022
On Fri, 2 Dec 2022 07:11:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> Simple fix for a printout regression.
>
> If NMT encounters a corrupted block, it is supposed to print a report about block and corruption. This includes hex dumps from both header and corruption point, as well as corruption address. Corruption address can be far away, if the block footer had been overwritten. In that case we also want to see two hex dumps (header and corruption location).
>
> This was introduced with [JDK-8275320](https://bugs.openjdk.org/browse/JDK-8275320), and worked, but regressed in the course of a code revamp with [JDK-8292071](https://bugs.openjdk.org/browse/JDK-8292071).
>
> Fix fixes the printout.
>
> before: wrong corruption address was printed:
>
>
> [ RUN ] NMT.test_overwrite_back_long_unaligned_distance_vm_assert
> NMT overwrite death test, please ignore subsequent error dump.
> NMT Block at 0x00005587f87632b0, corruption at: 0x00005587f87632b0:
> 0x00005587f8763230: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763240: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763250: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763260: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763270: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763280: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005587f8763290: ab ab ab ab ab ab ab ab e8 8e 00 00 00 00 00 00
> 0x00005587f87632a0: 00 00 00 00 00 00 00 00 21 20 00 00 00 00 00 00
> 0x00005587f87632b0: 01 20 00 00 00 00 00 00 00 00 00 00 0f 00 9e e9
> 0x00005587f87632c0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f87632d0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f87632e0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f87632f0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f8763300: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f8763310: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x00005587f8763320: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> [ OK ] NMT.test_overwrite_back_long_unaligned_distance_vm_assert (101 ms)
>
>
> With fix: correct corruption address is printed, and we have a second hexdump around the far corruption point:
>
>
> [ RUN ] NMT.test_overwrite_back_long_unaligned_distance_vm_assert
> NMT overwrite death test, please ignore subsequent error dump.
> NMT Block at 0x0000559090583020, corruption at: 0x0000559090585031:
> 0x0000559090582fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0000559090582fb0: 20 00 00 00 00 00 00 00 21 00 00 00 00 00 00 00
> 0x0000559090582fc0: 00 00 00 00 01 00 00 00 02 00 00 00 ab ab ab ab
> 0x0000559090582fd0: ab ab ab ab ab ab ab ab 21 00 00 00 00 00 00 00
> 0x0000559090582fe0: 00 00 00 00 02 00 00 00 ab ab ab ab ab ab ab ab
> 0x0000559090582ff0: ab ab ab ab ab ab ab ab 21 00 00 00 00 00 00 00
> 0x0000559090583000: 60 2f 58 90 90 55 00 00 ab ab ab ab ab ab ab ab
> 0x0000559090583010: ab ab ab ab ab ab ab ab 21 20 00 00 00 00 00 00
> 0x0000559090583020: 01 20 00 00 00 00 00 00 00 00 00 00 0f 00 9e e9
> 0x0000559090583030: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583040: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583050: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583060: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583070: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583080: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090583090: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> ...
> 0x0000559090584fb0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090584fc0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090584fd0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090584fe0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090584ff0: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090585000: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090585010: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090585020: f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1
> 0x0000559090585030: f1 61 8e ab ab ab ab ab d1 2f 01 00 00 00 00 00
> 0x0000559090585040: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x0000559090585050: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x0000559090585060: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x0000559090585070: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x0000559090585080: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x0000559090585090: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> 0x00005590905850a0: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> [ OK ] NMT.test_overwrite_back_long_unaligned_distance_vm_assert (101 ms)
Thanks Matthias!
> Btw I noticed that in
>
> src/hotspot/share/services/mallocTracker.cpp
>
> MallocTracker::print_pointer_information
>
> 224 address p_corrupted; 225 if (os::is_readable_pointer(mhdr) && 226 mhdr->check_block_integrity(msg, sizeof(msg), &p_corrupted)) {
>
> we also call check_block_integrity but in case of a failure we do not print out anything (unlike at the place you adjusted). Should we also do some handling for check_block_integrity returning false there (of course that is another issue) ?
I think its only used for "call pp()" in gdb. In that case, it reports true if it printed something, false if it didn't. I think the idea is to use it in a chain of similar calls, and the one responsible for the pointer would print something and return true; if not responsible it should keep quiet and return false.
-------------
PR: https://git.openjdk.org/jdk/pull/11472
More information about the hotspot-runtime-dev
mailing list