RFR(S): 8211852: inspect stack during error reporting
david.holmes at oracle.com
Tue Oct 9 01:34:42 UTC 2018
On 8/10/2018 10:54 PM, Doerr, Martin wrote:
> after making os::print_location more reliable, I'd like to use it to inspect the top of the stack, too (in a dedicated step).
> We already inspect the registers during error reporting, but some important pointers may be only on stack, especially on architectures which don't have so many registers.
> Since hs_err files are often all we get after a crash, it is often valuable to spend a little space for more information about what's referenced on top of the stack.
> I've uploaded my proposal here:
> I had thought about using print_location in the platform specific code (print_context), but I think using a dedicated step is better. Especially if print_location doesn't work we'll still get the dump of the context which contains a piece of the stack as hex dump without any further inspection.
> Please review.
What is the actual output format of a line? I guessing it will look
0x12345679 points into unknown readable memory: (byte 1 of) 0x12345678:
The "(byte 1 of)" looks a little odd to me. And it doesn't combine
cleanly with the print_hex_dump output. Do we really need print_hex_dump
just for dereferencing one address?
Seems odd to have:
751 STEP("printing top of stack info")
769 STEP("printing registers, top of stack, instructions near pc")
as they both refer to "top of stack". Should they be merged (I know you
touch on this above)? Should they be the other way round? Should they
use different descriptions?
Any particular reason to show 8 slots? Or is it just a "Goldilocks number"?
> Best regards,
More information about the hotspot-runtime-dev