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

[Thomas Stüfe]

On Tue, Jan 29, 2019 at 11:31 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 1/29/19 6:13 AM, David Holmes wrote:
> > 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.
>
> SafeFetch-based probing implemented here:
>   http://cr.openjdk.java.net/~shade/8217879/webrev.03/
>
> When you hack the code to pass pc=NULL, it would print:
>
> Instructions: (pc=0x0000000000000000)
> Memory is not readable
>

I would bail out right away for bogus/unreadable pc since those may happen
more often than not.

Is this exponential stepping really necessary? You run a risk of loosing
information, e.g. for a pc 250 bytes int a readable page preceeded with an
unmapped one. This coding runs during error reporting, so no big speed
concerns I think.

Rest is fine.


> > 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.
>
> I don't know what your users submit on JVM crashes, but for us the
> availability of the core dump is
> an exception rather than the rule. Most of the time all we have is hs_err.
> Having a little bit more
> context does help figuring out what went wrong.
>

+1 !

..thomas


>
> -Aleksey
>
>