RFR: JDK-8299790: os::print_hex_dump is racy [v2]
Thomas Stuefe
stuefe at openjdk.org
Mon Aug 7 09:47:31 UTC 2023
On Mon, 7 Aug 2023 08:29:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> Looks good.
>
> It's a pity that we would read full `intptr_t` for every unit, which would mean that reading byte-unit block of N bytes would issue 8*N SafeFetch reads. But I guess it is fine, given the old code did `SafeFetch32` anyway.
I thought about this too but then refrained from implementing a "read intptr_t then print bytes" to keep the patch complexity low.
I think another, simpler, patch would be worthwhile where we split print_hex_dump into two variants, one using SafeFetch and one just reading, and use the former one only if we are unsure about the memory content. E.g. at hs-err file dumping. There is no need to pay for SafeFetch when hexdumping e.g. for logging.
Maybe for a future RFE.
>
> That looks like fixing another implicit bug, if we are reading the unaligned 64-bit location at readable boundary: `is_readable_pointer` would read 32-bits and return `true` for first 4 bytes of the location, and then we go in and read 64 bits with `print_hex_readable_pointer` with `unitsize = 8`. Which might break if the last 4 bytes of that read are actually outside the readable range.
Oh, I missed that. Nice :)
Thanks for the review!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14895#issuecomment-1667539639
More information about the hotspot-runtime-dev
mailing list