RFR(T): 8224034: [TESTBUG] runtime/ErrorHandlerTest/ErrorHandler fails intermittently for case 13 on Windows

[Thomas Stüfe]

Hi David,

On Tue, May 21, 2019 at 9:02 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> First can you fix the synopsis of the bug before pushing anything as the
> test is:
>
> runtime/ErrorHandling/ErrorHandler.java
>
> Thanks. :)
>
>
Done :)


> On 21/05/2019 4:21 pm, Thomas Stüfe wrote:
> > Hi all,
> >
> > may I have reviews please for this trivial test fix:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8224034
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8224034-errorhandlertest-13-fails-intermittently/webrev.00/webrev/
> >
> > -XX:ErrorHandlerTest=13 may sometimes fail to trigger the expected crash.
> > We see this on Windows. Where one would expect a ACCESS_VIOLATION, the VM
> > just quits immediately.
>
> Just a data point but I did some checking and AFAICS we do not see any
> such failures. You must have some interesting config on your Windows
> boxes. :)
>
>
Yes, I wondered about that too.


> > The test jumps to an invalid function pointer. We may see here some sort
> of
> > intrusion prevention.
> >
> > All these tests invoke undefined behavior but the other tests behave in
> the
> > expected fashion.
> >
> > I propose to exclude this case from the test since analyzing why exactly
> it
> > quits immediately on Windows could be done but IMHO is not worth the
> effort.
>
> Is it worth just skipping it on Windows? I know that will make the test
> logic more awkward. Your call.
>

I rather not. The error handler test should test that -XX:ErrorHanderTest
works as expected, and we had several discussions in the past (e.g. with
Kim) about this. But we may cut down - in a separate issue - the number of
cases. Cases which cannot be triggered reliably are not that useful.

Cheers, Thomas


>
> Thanks,
> David
>
> > Thank you!
> > Thomas
> >
>