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. 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.