Why no hs_err on SIGABRT?

[Thomas Stüfe]

Hi Maxim,

it would be technically a bit fiddly, since the hotspot uses abort(3) at
the end of the error reporting to generate a core; you'd have to prevent
circularities, e.g. by carefully switching off the abort handler before
calling abort.

Then, I believe it would break downward compatibility, since if the VM
starts to use SIGABORT that could conflict with existing applications that
have abort handler registered, requiring them to start using signal
chaining.

It also could break compatibility in a different way, prolonging the time
it takes for the VM to react on a SIGABORT, since error reporting takes
time (we have a complex time out mechanism in the error reporter for that
reason). Applications that abort VM processes and expect those to go
quickly may need to switch to a different signal. There is also the
understanding that SIGABORT kills the process immediately with a core; that
core file would get delayed and could therefore be less useful.

Those are from the top of my head, there may be more issues. Certainly
solvable, but I am not sure the benefit would be that great. In those rare
instances where I had the glibc abort on me, the call stack made it
immediately clear what the problem was. As of
https://bugs.openjdk.org/browse/JDK-8275320, NMT does sanity checks on
malloc/free, enabling us to have those checks in release builds (just
switch on NMT). That leaves allocations from outside hotspot, but there,
the hs-err file would be less useful anyway.

Cheers, Thomas

On Thu, Jun 9, 2022 at 10:39 AM Maxim Kartashev <
maxim.kartashev at jetbrains.com> wrote:

> The very useful hs_err file gets generated in many abnormal situations, but
> program termination by abort() (which generates SIGABRT) isn't one of them.
> I was wondering if this is deliberate and, if so, why?
>
> The use case I have in mind is the utilization of the built-in GNU libc
> heap checks. If, for example, there's a double-free, a chance exists for
> those checks to fire and terminate the program with abort(). In absence of
> core dump, hs_err would provide at least some guidance as to the location
> of the problematic code and, unlike the core file, it will have the java
> stack readily available. It is also quite common for the developers to
> receive hs_err files, but not core files, which are a lot larger, may have
> sensitive information in them, and are often not generated by default.
>