none

[Donald Kwakkel]

So you mean that if jsvc is not used the hang will not occur? Because if I
look at the stack I do not see any jsvc related code executed.
(Indeed I am not looking howto make sure not to crash, but how to make sure
a crash will not hang).

Is it possible to disable the verbose crash report?

Op ma 30 sep. 2019 om 14:55 schreef Florian Weimer <fweimer at redhat.com>:

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