RFR (s) 8251383: Disable Event::log from linux_mprotect when processing the assertion poison page

[Thomas Stüfe]

Hi David,

ugh. Sorry for the complexity. Our compiler guys really liked this feature,
but I still have the nagging feeling this was not my best development ever
(or, more precisely, that the added complexity may not be worth the
information).

As for the patch, you should use CAN_SHOW_REGISTERS_ON_ASSERT instead of
ASSERT/DEBUG since this may break zero. See debug.hpp.

Cheers, Thomas


On Tue, Aug 11, 2020 at 11:17 AM David Holmes <david.holmes at oracle.com>
wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8251383
> webrev: http://cr.openjdk.java.net/~dholmes/8251383/webrev/
>
> When the assertion poison page is enabled (Linux only and on by default)
> the signal handler will call os::protect_memory to change the page
> protection bits. That will call linux_mprotect which will call
>
> Events::log(NULL, "Protecting memory [" INTPTR_FORMAT "," INTPTR_FORMAT
> "] with protection modes %x", p2i(bottom), p2i(bottom+size), prot);
>
> Event logging in turn can use Mutexes and other VM facilities - all of
> which are now being executed in a signal handling context (which is
> inherently unsafe). It also means that there cannot be any other failing
> assertions on that path as you will re-trigger the poison page pagefault
> and abort with no hs_err file. Hence, as happened to me, a failing
> assertion in the mutex code triggers this problem.
>
> The issue can be worked-around by setting -XX:-ShowRegistersOnAssert
> (once you realise what is happening).
>
> The simple fix is to skip the logging if the faulting address is the
> poison page address.
>
> This only affects debug builds of course.
>
> Testing:
>    - runtime/ErrorHandling
>    - tier 1-3
>
> Thanks,
> David
>