POSIX 信号行为
如果一个进程当前由于 SIGTRAP 信号而停止，并且通过 Kill() 向它发送了 SIGSTOP 信号，那么默认行为是什么？ SIGSTOP 是否是进程再次继续后传递的待处理信号？或者它会被丢弃/忽略吗？
如果 SIGSTOP 已排队，是否有任何方法可以从该进程外部（例如在跟踪进程中）将其从队列中删除？
If a process is currently stopped due to a SIGTRAP signal and it is sent 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
来自 signal(7) 手册页：
一个简单的测试，应用程序在断点处停止并向其发送
SIGSTOP显示当我点击“下一步”时 gdb 显示一些信息。信号显然已传递到应用程序。在我向它发送SIGCONT之前，它无法继续调试。From the signal(7) man page:
A simple test with an app stopped on a breakpoint and sending it a
SIGSTOPshows 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 aSIGCONT.“由于 SIGTRAP 信号而停止”是什么意思？ SIGTRAP 不会停止进程；默认情况下，它将以核心转储终止，或者您可以将其更改为忽略信号或调用信号处理程序，但在任何情况下，SIGTRAP 都不会自行停止进程。您可能让某个其他进程（例如调试器）使用 ptrace(2) 跟踪该进程，在这种情况下，它将在传递 SIGTRAP 之前停止，但在这种情况下，它处于 ptrace 的控制之下，并且不会继续，直到出现 PTRACE_CONT 或其他 ptrace 操作来继续该过程。
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.