RFR (S) 8217994: os::print_hex_dump should be more resilient against unreadable memory

[Schmidt, Lutz]

Hi Aleksey,

I like the added resilience! I'm not a reviewer, though.

When looking at the newly introduced else branch, I had the idea of replacing the entire switch by

  st->print("%*s", 2*unitsize, "????????????????");

Like it? I do!

Thanks, 
Lutz

On 29.01.19, 18:46, "hotspot-dev on behalf of Thomas Stüfe" <hotspot-dev-bounces at openjdk.java.net on behalf of thomas.stuefe at gmail.com> wrote:

    Looks good.
    
    Note that this coding assumes (always did) that the input pointer is
    aligned to the unitsize, otherwise the printing would not work on platforms
    which do not allow unaligned loads.
    
    This means that if the pc in the ucontext is unaligned rubbish we may crash
    on platforms where we print with a unitsize > 1 and unaligned access is not
    allowed.
    
    But your patch does not make the problem worse, so it is fine to me.
    
    Cheers, Thomas
    
    
    
    
    
    
    
    On Tue, Jan 29, 2019 at 5:54 PM Aleksey Shipilev <shade at redhat.com> wrote:
    
    > RFE:
    >   https://bugs.openjdk.java.net/browse/JDK-8217994
    >
    > Fix:
    >   http://cr.openjdk.java.net/~shade/8217994/webrev.01/
    >
    > This is related to JDK-8217879 (hs_err should print more instructions in
    > hex dump), and this more
    > generic fix should cover more cases in error handler. New gtest verifies
    > we can call os::p_h_d on
    > bad memory now. It also implicitly verifies that SafeFetch machinery works
    > fine. Consider running
    > that gtest (make images run-test TEST=gtest:os) on your platform if you
    > suspect it does not.
    >
    > Testing: (Linux, Windows) x86_64 build, gtest, eyeballing gtest output
    >
    > Thanks,
    > -Aleksey
    >
    >