RFR(S): 8211852: inspect stack during error reporting (original) (raw)

David Holmes david.holmes at oracle.com
Tue Oct 9 01:34:42 UTC 2018

Hi Martin,

On 8/10/2018 10:54 PM, Doerr, Martin wrote:

Hi,

after making os::printlocation 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 hserr 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: http://cr.openjdk.java.net/~mdoerr/8211852stackinfo/webrev.00/ I had thought about using printlocation in the platform specific code (printcontext), but I think using a dedicated step is better. Especially if printlocation 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.

src/hotspot/share/runtime/os.cpp

What is the actual output format of a line? I guessing it will look something like:

0x12345679 points into unknown readable memory: (byte 1 of) 0x12345678: 0xCAFEBABE

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?

src/hotspot/share/utilities/vmError.cpp

Seems odd to have:

751 STEP("printing top of stack info")

then

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"?

Thanks, David

Best regards, Martin

More information about the hotspot-runtime-dev mailing list