How is the signalling(interrupts) mechanism handled in kernel? The cause why I ask is: so开发者_运维知识库mehow a SIGABRT signal is received by my application and I want to find where does that come from..
You should be looking in your application for the cause, not in the kernel.
Usually a process receives SIGABRT
when it directly calls abort
or when an assert
fails. Finding exactly the piece of the kernel that delivers the signal will gain you nothing.
In conclusion, your code or a library your code is using is causing this. See abort(3)
and assert
.
cnicutar's answer is the best guess IMHO.
It is possible that the signal has been emitted by another process, although in the case of SIGBART it most likely to be emitted by the same process which receives it via the abort(3)
libc function.
In doubt, you can run your application with strace -e kill yourapp you args ...
to quickly check if that kill
system call is indeed invoked from within your program or dependent libraries. Or use gdb catch syscall
.
Note that in some cases the kernel itself can emit signals, such as a SIGKILL
when the infamous "OOM killer" goes into action.
BTW, signals are delivered asynchronously, they disrupt the normal workflow of your program. This is why they're painful to trace. Besides machinery such as SystemTap I don't know how to trace or log signals emission and delivery within the kernel.
精彩评论