RFR (S) 8217879: hs_err should print more instructions in hex dump

[David Holmes]

Hi Aleksey,

On 29/01/2019 2:48 am, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8217879
> 
> Fix:
>    http://cr.openjdk.java.net/~shade/8217879/webrev.01/
> 
> "Instructions" block is useful when following up on hs_errs that happened without the disassembler
> attached, which is usually the case coming from users. One can use the disassembler [1] to look
> around the code that was crashing, and get extended conjectures why the error happened, including
> rewinding a bit of history. However, current window is sometimes too small to infer enough context.
> I propose we extend it!

The existing comment states:

    // Note: it may be unsafe to inspect memory near pc. For example, pc may
     // point to garbage if entry point in an nmethod is corrupted. Leave
     // this at the end, and hope for the best.

so by increasing the size of the block you are potentially greatly 
increasing the risk that you will do something unsafe. Perhaps, as 
Thomas suggested, if you really want to expand this range it should be 
done in a more safe manner.

I'm also very much in favour of the slimmer hs_err file. At this rate of 
expansion the hs_err file will look more like a core file, and we 
already have core files for that. ;-) hs_err files were never intended 
to be a one-stop debugging shop.

Cheers,
David
-----

> The patch also commons the paths across OS/Arch-specific files to that current "delta" appears less
> of the magic number. Plus, it adds cr()-s for consistency across the arches and within the methods.
> 
> Testing: eyeballing hs_errs from artificial crashes, Linux x86_64 build, jdk-submit
> 
> Thanks,
> -Aleksey
> 
> [1] I use https://onlinedisassembler.com, for example.
>