SIGABRT signals don't create core dumps

Mon Feb 16 11:27:48 UTC 2026

I believe what happens is that something has a bug and does an invalid 
call to free() that makes glibc to call abort(). And since there is no 
handler for that, nothing generates a core dump and it just ends.

Based on this stackoverflow post:
https://stackoverflow.com/a/151568

     As for how to debug it, installing a handler for SIGABRT is probably the best way to proceed. You can set a breakpoint in your handler or deliberately trigger a core dump.

Álvaro

On 16/2/26 11:41, David Holmes wrote:
> On 13/02/2026 7:25 pm, Álvaro Torres Cogollo wrote:
>> Hi,
>>
>> In my opinion, I think it's fair to assume that other libraries 
>> shouldn't call abort() if they actively don't want it to generate a 
>> core dump. At least in the context of a Spring Boot server, I can't 
>> think of a valid reason to call abort from a library and don't expect 
>> a core dump.
>
> My query is: how is it calling abort but not getting a coredump?
>
> David
>> However, I understand the concern about handling SIGABRT signals in 
>> hosting environments. I'm also missing a huge context on the 
>> implications of this. Maybe it's enough to create a flag like -XX: 
>> +CreateCoreDumpOnAbort, -XX:+HandleAbort or -XX:+CrashOnAbort. That 
>> could be a best-practice configuration so far in certain contexts 
>> (Spring Boot) and eventually consider making this the default behaviour.
>>
>> Regards,
>>
>> Álvaro
>>
>>
>> On 13/2/26 08:07, David Holmes wrote:
>>> Hi,
>>>
>>> On 13/02/2026 3:16 am, Álvaro Torres Cogollo wrote:
>>>> Hi again,
>>>>
>>>> I just realized that I made a typo in the reproduction repository 
>>>> link. This is the right one:
>>>>
>>>> https://github.com/atorrescogollo/poc-jdk-sigabrt-coredump-bug
>>>>
>>>> Sorry about that.
>>>>
>>>> Álvaro
>>>>
>>>>
>>>> On 12/2/26 18:04, Álvaro Torres Cogollo wrote:
>>>>> Hi,
>>>>>
>>>>> We've been hitting a problem in production that I think might be a 
>>>>> bug in hotspot's signal handling. Let me know if this should go 
>>>>> somewhere else.
>>>
>>> This is the right place (hotspot-runtime-dev would also have done 
>>> but a narrower audience).
>>>
>>> Not sure it is a bug as such. I'm missing a piece of the puzzle 
>>> here. These other libraries are presumably calling abort() to raise 
>>> the SIGABRT but there is no coredump. Yet if the VM calls abort() 
>>> there is a coredump. I'm not seeing why there would be different 
>>> behaviour.
>>>
>>> Catching SIGABRT in the VM then re-calling abort() may fix your 
>>> issue, but I'm not sure if it could introduce problems for hosting 
>>> environments which may already catch SIGABRT themselves.
>>>
>>> Need to hear what other think about this.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>>> The issue is that when a native library crashes due to memory 
>>>>> corruption (like an invalid free() call), the JVM exits 
>>>>> immediately without generating any core dump or error report, even 
>>>>> though we have -XX:+CreateCoredumpOnCrash enabled.
>>>>>
>>>>> Here's what we're seeing when it crashes:
>>>>>      munmap_chunk(): invalid pointer
>>>>>
>>>>> Or when using tcmalloc:
>>>>>      src/tcmalloc.cc:333] Attempt to free invalid pointer 
>>>>> 0xffff38000b60
>>>>>
>>>>> We're running with:
>>>>>      JAVA_TOOL_OPTIONS=-XX:+CreateCoredumpOnCrash -XX:ErrorFile=/ 
>>>>> core-dumps/hs_err_pid%p.log
>>>>>
>>>>> But when these crashes happen, we get nothing - just the error 
>>>>> message above and the process dies. This makes debugging really 
>>>>> difficult, especially since the crashes happen randomly in 
>>>>> production.
>>>>>
>>>>> After digging through the hotspot source, I noticed that signal 
>>>>> handlers are installed for SIGSEGV, SIGBUS, SIGFPE, etc., but not 
>>>>> for SIGABRT:
>>>>>
>>>>> https://github.com/openjdk/jdk/ 
>>>>> blob/37dc1be67d4c15a040dc99dbc105c3269c65063d/src/hotspot/os/posix/ 
>>>>> signals_posix.cpp#L1352-L1358
>>>>>
>>>>> When glibc detects the memory corruption, it calls abort() which 
>>>>> raises SIGABRT. Since there's no handler for it, the JVM can't 
>>>>> catch it and generate the diagnostics.
>>>>>
>>>>> To demonstrate the issue, I put together a small reproduction case:
>>>>>
>>>>> https://github.com/atorrescogollo/poc-jdk-sigabrt-coredump-handling
>>>>>
>>>>> The repo has a Spring Boot app with three endpoints that show the 
>>>>> problem:
>>>>>
>>>>> 1. /crash/unsafe - Uses Java Unsafe to write to address 0
>>>>>    Result: SIGSEGV -> Works correctly, generates hs_err file
>>>>>
>>>>> 2. /crash/null - JNI code that dereferences a null pointer
>>>>>    Result: SIGSEGV -> Works correctly, generates hs_err file
>>>>>
>>>>> 3. /crash/free - JNI code that calls free() on a stack variable
>>>>>    Result: SIGABRT -> BROKEN, just prints "munmap_chunk(): invalid 
>>>>> pointer" and dies
>>>>>
>>>>> You can reproduce it with:
>>>>>      docker-compose up -d
>>>>>      curl localhost:8080/crash/free
>>>>>      docker-compose logs
>>>>>
>>>>> And you'll see it just prints the error and exits, no hs_err file 
>>>>> gets created.
>>>>>
>>>>> I also tested a potential fix by adding SIGABRT handling to 
>>>>> hotspot. With that change, scenario 3 correctly generates an 
>>>>> hs_err file and core dump. The patch basically:
>>>>>
>>>>> https://github.com/atorrescogollo/poc-jdk-sigabrt-coredump-bug/blob/ 
>>>>> main/jdk17.patch
>>>>>
>>>>> - Adds set_signal_handler(SIGABRT) in signals_posix.cpp
>>>>> - Resets SIGABRT to SIG_DFL before calling abort() in os_posix.cpp 
>>>>> to avoid recursive handling
>>>>>
>>>>> After applying it, the /crash/free endpoint generates proper 
>>>>> diagnostics:
>>>>>      # SIGABRT (0x6) at pc=0x0000ffffbd177608 (sent by kill), 
>>>>> pid=1, tid=41
>>>>>      # Problematic frame:
>>>>>      # C  [libc.so.6+0x87608]
>>>>>      # Core dump will be written. Default location: //core
>>>>>      # An error report file with more information is saved as:
>>>>>      # /core-dumps/java_error1.log
>>>>>
>>>>> I'm not sure if there's a specific reason why SIGABRT isn't 
>>>>> handled currently. If there is, are there any alternative 
>>>>> approaches to capture diagnostics when native libraries trigger 
>>>>> abort()? For us and probably others dealing with native library 
>>>>> bugs in production, having some way to get these diagnostics would 
>>>>> be really valuable.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Álvaro
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20260216/2d2a1470/attachment-0001.htm>