none

[Florian Weimer]

* 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
> https://stackoverflow.com/questions/40049751/malloc-inside-linux-signal-handler-cause-deadlock).
>
>
> 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
> /usr/java/latest/lib/server/libjvm.so
> #12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
> /usr/java/latest/lib/server/libjvm.so
> #13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
> /usr/java/latest/lib/server/libjvm.so
> #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.

Thanks,
Florian