fweimer at redhat.com
Mon Sep 30 12:55:31 UTC 2019
* Donald Kwakkel:
> Is this a known issue / are there workarounds?
Yes, sort of, we've seen it many times with in-process crash handlers.
> If during malloc a crash signal occurs, the jvm will hang because it will
> call again malloc, which is not reentrant (for explanation see
> This is for production environments a big problem because self-healing (in
> this case an automatic restart through jsvc) will not work. Resulting in
> manual actions by cloud administrators!
The recommended practice is to use a crash handler external to the
process. Of course, this is not going to fix the underlying issue which
causes the crash.
> #11 0x00007f123a9fbbae in VMError::report_and_die(Thread*, unsigned
> int, unsigned char*, void*, void*) () from
> #12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
> #13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
> #14 <signal handler called>
> #15 0x0000003ce2c7856c in _int_malloc () from /lib64/libc.so.6
The question is whether a verbose crash report is actually needed if the
PC value (as recorded in the siginfo* argument) is within libc.so.6.
Maybe in this case, a more limited crash dump is appropriate.
More information about the hotspot-dev