调试信号需三步：先查/proc/[pid]/status确认信号是否pending或被阻塞；再用strace验证signal()/sigaction()注册是否生效；最后分键盘、kill、异常、定时等场景主动触发并观察行为，同时排查屏蔽、竞态与线程接收问题。
调试程序对信号的反应，核心是观察“信号是否被正确收到”、“是否按预期方式处理”以及“有没有被意外阻塞或忽略”。这不是靠猜，而是有明确路径可循。
确认信号是否真正到达进程
信号没被处理，第一步先看它到底有没有到。Linux 把每个进程的待处理信号记在 PCB 的 pending 位图里，可以用 kill -l 查信号编号，再用 cat /proc/[pid]/status | grep Sig 查实时状态：
- SigQ 显示当前队列中未决信号总数和系统上限
- SigPnd（Pending）是该进程已产生但尚未递达的信号掩码（十六进制），对应位为 1 表示该信号处于未决状态
- ShdPnd（Shared Pending）是线程组共享的未决信号
- SigBlk（Blocked）是当前被阻塞的信号掩码——如果某信号在 SigBlk 中对应位为 1，那它即使产生也卡在 pending 状态，不会触发处理
例如：运行 ./a.out & 后查到 SigBlk: 0000000000000004，换算成二进制末位第 3 位是 1，说明 SIGQUIT（编号 3）被阻塞了，此时发 kill -3 [pid] 不会有任何反应——不是没发成功，是被挡住了。
验证信号处理函数是否注册生效
用 signal() 或 sigaction() 设置处理函数后，不能只信代码逻辑，要实测注册结果。最直接的方法是用 strace 跟踪系统调用：
- 运行 strace -e trace=signal,rt_sigaction ./a.out
- 启动后看到类似 rt_sigaction(SIGINT, {sa_handler=0x4011b6, ...}, ...) 就说明 SIGINT 处理函数地址已成功注册
- 若看到 rt_sigaction(SIGUSR1, {sa_handler=SIG_IGN}, ...)，说明该信号被显式忽略
- 若某信号完全没出现在 strace 输出里，很可能程序根本没调用注册函数，或在 fork 后子进程未重新注册（信号处理函数不继承）
触发信号并观察行为细节
别只依赖 Ctrl+C，要分场景主动触发、对照预期：
- 键盘信号：前台进程用 Ctrl+C（SIGINT）、Ctrl+\（SIGQUIT）、Ctrl+Z（SIGTSTP），注意后台进程收不到终端生成的这些信号
- 命令发送：用 kill -TERM [pid] 测试优雅终止；用 kill -USR2 [pid] 测试自定义逻辑（确保程序注册了 SIGUSR2）
- 异常触发：故意写 int *p = nullptr; *p = 1; 触发 SIGSEGV，看是否走自定义 handler 还是直接 core dump；配合 ulimit -c unlimited 和 gdb core.xxx 定位崩溃点
- 定时信号：调用 alarm(2) 后等待 SIGALRM，用 strace 看是否如期抵达，避免 sleep 误判
检查屏蔽与竞态干扰
信号没响应，常因屏蔽字（sigprocmask）或处理中重入问题。调试时重点关注：
- 在关键代码段前后加 sigsuspend() 或 sigprocmask(SIG_BLOCK/UNBLOCK)，用 sigpending() 函数在代码中打印当前 pending 信号集，确认屏蔽是否按需生效
- 若 handler 中调用了非异步信号安全函数（如 printf、malloc），可能导致死锁或崩溃——改用 write(STDERR_FILENO, ...) 这类 async-signal-safe 函数临时打日志
- 多个线程时，信号默认只发给一个线程（通常是主线程），用 pthread_sigmask() 控制哪个线程接收，避免“发了却没人收”
