Fix SIGABRT not causing a core dump#10416
Conversation
A second abort() is needed at the end of `SigAbrtHandler()` to trigger the SIG_DFL action (in this case the core dump). Also since `AttachDebugger()` disables the ability to dump core, so it gets reenabled after returning from it.
julianbrost
left a comment
julianbrost
left a comment
There was a problem hiding this comment.
A second abort() is needed at the end of
SigAbrtHandler()to trigger the SIG_DFL action (in this case the core dump).
That's actually only necessary when triggering this by only sending SIGABRT (for example using kill -ABRT $icinga2_pid externally). Calling abort() within the Icinga 2 process actually does something similar by itself already (man 3 abort:
If the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by restoring the default disposition for SIGABRT and then raising the signal for a second time.
Adding the second abort() that actually fixes a strange problem I observed during testing: Before, when sending SIGABRT externally, it would log that "critical/Application: Icinga 2 has terminated unexpectedly. Additional information can be found in [...]" message but actually continue running (sending SIGABRT a second time then terminated it using the default handler).
4 participants
A second abort() is needed at the end of
SigAbrtHandler()to trigger the SIG_DFL action (in this case the core dump).Also since
AttachDebugger()disables the ability to dump core, so it gets reenabled after returning from it.I've tested and verified that the backtraces generated with
gdbinAttachDebugger()still appear in the crash-log file.This fixes #8908.
I will address the documentation changes for #8714 in a second PR.