Why no hs_err on SIGABRT?

[Maxim Kartashev]

Thomas,

thanks you so much for the info! That was quite helpful.

On Fri, Jun 10, 2022 at 3:02 PM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

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