开发者

Where linux signals are sent or processed inside the kernel?

开发者 https://www.devze.com 2023-03-19 19:57 出处:网络
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 f

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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号