gdb调试时应使用handle sigpipe nostop noprint pass（同理适用于sigurg、sigchld），而非signal命令；handle全局设置信号传递语义，使gdb不中断但保持信号正常送达程序，避免误触发线程崩溃。
gdb调试时如何忽略 SIGPIPE、SIGURG 等系统调用相关信号
默认情况下，GDB 会捕获并暂停程序执行，哪怕只是内核返回了一个被忽略的系统调用错误（如 write 向已关闭管道写入触发 SIGPIPE，或 recv 收到带外数据触发 SIGURG）。这类信号在多线程服务中很常见，但往往不是你要查的 bug，反而会频繁打断调试节奏。
解决方法不是屏蔽信号，而是让 GDB **不中断**，同时保持信号正常传递给程序：
- 启动 GDB 后，立即执行：
handle SIGPIPE nostop noprint pass - 同理可设：
handle SIGURG nostop noprint pass、handle SIGCHLD nostop noprint pass -
nostop：收到时不暂停；noprint：不打印“Program received signal…”提示；pass：仍把信号发给目标程序（由程序自己的 signal handler 或默认行为处理） - 若想临时恢复中断，用
handle SIGPIPE stop print即可
为什么不能直接用 signal SIGPIPE ignore？
signal 命令在 GDB 中是「向当前线程发送信号」，不是设置信号处理策略。误用 signal SIGPIPE 可能直接 kill 当前线程（尤其在没注册 handler 时），导致调试会话意外退出或线程状态错乱。
真正控制信号处置方式的，只有 handle 命令。它作用于整个调试会话，影响所有线程对指定信号的响应行为。
- 常见误操作：
signal SIGPIPE→ 触发kill -13效果，主线程可能崩溃 - 正确做法始终用
handle配置信号传递语义 - 可通过
info signals查看当前所有信号的处理配置
多线程下 SIGPIPE 被哪个线程接收？
POSIX 规定：未被阻塞的信号（如 SIGPIPE）会递送给「任意一个未阻塞该信号的线程」，不保证是发起系统调用的那个线程。这意味着：
- 即使你在业务线程里
write()导致管道破裂，SIGPIPE也可能送到主线程或 IO 线程 - 如果你只对某线程
handle SIGPIPE nostop，实际无效——handle是全局设置，无法 per-thread - 若需线程粒度控制，必须在代码中用
pthread_sigmask()显式阻塞/解除阻塞，再配合handle全局策略
所以，别指望靠切换线程再设 handle，GDB 的 handle 没有线程上下文绑定。
调试中突然停在 sigprocmask / futex_wait 是什么情况
这不是信号问题，而是线程调度卡点。当 GDB 暂停时，内核可能正处在 futex_wait、sigprocmask 或 epoll_wait 等系统调用中，此时 bt 显示的是内核入口，而非你的业务栈帧。
- 先执行
thread apply all bt，确认是否所有线程都卡在等待状态 - 检查是否有线程在
pthread_mutex_lock后没释放，导致其他线程死等 - 用
info registers看rdi/rsi寄存器值，结合info proc mappings判断是否真在系统调用里 - 这种情况通常和信号无关，别急着加
handle，先查锁和资源竞争
真正难搞的，永远不是信号本身，而是信号背后暴露的线程协作缺陷——比如一个线程提前 close 了共享 socket，另一个线程还在 read，这时 SIGPIPE 只是表象，根源在生命周期管理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
