开发者

POSIX signal behavior

If a process is currently stopped due to a SIGTRAP signal and it is se开发者_StackOverflownt a SIGSTOP signal via kill(), what would be the default behavior? Would the SIGSTOP be a pending signal that is delivered after the process continues again? Or will it just be discarded/ignored?

If the SIGSTOP is queued up, is there any way to remove it from the queue from outside of that process, such as in a tracing process?


From the signal(7) man page:

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

A simple test with an app stopped on a breakpoint and sending it a SIGSTOP shows gdb displaying some information when I hit 'next'. The signal was obviously delivered to the app. It cannot continue to be debugged until I send it a SIGCONT.

(gdb) next
Program received signal SIGSTOP, Stopped (signal).
fill (arr=0x7fffffffdff0, size=5) at tmp.cpp:28
(gdb) next
Program received signal SIGCONT, Continued.
fill (arr=0x7fffffffdff0, size=5) at tmp.cpp:28
(gdb) next
(gdb) 


What do you mean 'stopped due to a SIGTRAP signal'? A SIGTRAP will not stop a process; by default it will terminate with a core dump, or you can change it to ignore the signal or call a signal handler, but in no case will the SIGTRAP stop the process by itself. You might have the process being traced by some other process (such as a debugger) with ptrace(2), in which case it will stop just before delivering the SIGTRAP, but in that case its under the control of the ptrace and won't continue until there's a PTRACE_CONT or other ptrace action to continue the process.

0

上一篇:

下一篇:

精彩评论

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

最新问答

问答排行榜