Why no hs_err on SIGABRT?

[David Holmes]

+1 to what Thomas said. I too have not had an issue with tracking down 
glibc aborts.

David

On 10/06/2022 10:02 pm, Thomas Stüfe 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.
>>