RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump"

[Thomas Stüfe]

On Mon, Feb 25, 2019 at 4:43 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/25/19 4:23 PM, Langer, Christoph wrote:
> > I discussed that with Thomas. Maybe we should align the start address
> down to unitsize in
> > os::print_hex_dump, instead of asserting.
>
> Yup. It is also arguably better UX: no matter what the start address is,
> we would always "granulate"
> the dumped memory the same way.
>

Yes.


>
> >> ...and print_hex_dump is supposed to be resilient, because I'd expect
> SafeFetch to handle
> >> SIGBUS from unaligned accesses too. I see the signal handler for
> linux_x86 and solaris_x86
> >> handle all signals, not only SEGVs. So, why did the test SIGBUS'ed?
> What a rabbit hole.
> >
>

It does, but not in a TEST since there no signal handler are installed.

In TEST_VM, VM is initialized, signal handler installed,
is_readable_pointer would work and the output would be empty.


> > Good point, will see if we can figure out more. Interestingly, the test
> crashes on one Solaris
> > machine (that tests jdk11u here), but not on another (where jdk/jdk is
> tested).
>
> Also, Oracle testing presumably builds/runs/tests Solaris, and there were
> no bug reports about it.
>
>
Note that this bug depends on the location of your stack local test array.
If C++ compiler happens to put it onto a quadword aligned address, error is
hidden.


> It looks that test had caught a legit problem, and as such does not look
> like a testbug.
>
>
Well, using TEST_VM instead of TEST is. The alignment stuff is not.


> -Aleksey
>
>