gdb 的 catch throw 默认只监控主线程
这是最常踩的坑：你在多线程程序里抛了异常，gdb 却完全不中断。根本原因不是 catch throw 失效，而是它默认只对当前线程（通常是主线程）生效。其他线程抛异常时，gdb 压根不感知。
实操建议：
- 启动 gdb 后，先用
info threads确认所有线程已加载（尤其是那些还没跑起来的 pthread） - 在
catch throw之前，执行set follow-fork-mode child（如果子进程/线程由 fork 启动） - 更关键的是：运行前加
set catch syscall tgkill或set catch syscall tkill—— 这能捕获内核向线程发信号的动作，间接覆盖异常传播路径（尤其对未被捕获的std::terminate有效）
必须用 catch throw + thread apply all 组合才真正生效
单独 catch throw 只作用于当前线程；想让所有线程都“装上断点”，得手动批量设置。
实操建议：
- 启动程序后，等所有工作线程创建完毕（可用
info threads数线程数确认），再执行：thread apply all catch throw
- 注意：这个命令会为每个线程单独注册一个 catch 点，gdb 输出里会出现一堆 “Catchpoint X (throw) for thread Y”
- 如果线程是动态创建的（比如线程池），新线程不会自动继承 catch 点，需在
pthread_create后手动对新thread id执行thread <id> catch throw</id>
调试时容易卡死或跳过断点？检查 libstdc++ 符号和优化级别
常见现象：catch throw 显示已设置，但异常一抛就直接 crash，gdb 没停住。大概率是符号缺失或编译器优化干扰了异常帧展开。
实操建议：
- 确认编译时用了
-g -O0（至少调试阶段禁用-O2及以上），否则libstdc++的__cxa_throw调用可能被内联或裁剪 - 运行前执行
set libstdcxx-exceptions on（gdb 8.0+ 默认开启，老版本需手动开） - 用
info functions __cxa_throw验证是否能查到该符号；查不到说明链接的是 stripped 版本的 libstdc++.so，需安装libstdc++6-dbgsym（Ubuntu/Debian）或debuginfo-install libstdc++（RHEL/CentOS）
定位异常源头比打断点更重要：用 thread apply all bt 看全貌
即使成功在某个线程停在 throw，你也只看到抛出点。而真实问题往往藏在线程初始化逻辑、共享对象状态或跨线程资源竞争里。
实操建议：
- 一触发
catch throw，立刻执行：thread apply all bt -n 10
（限制栈深度防卡死） - 重点看哪些线程处于
pthread_cond_wait、sem_wait或__lll_lock_wait—— 这些往往是异常前的阻塞点，暗示资源没释放或条件没满足 - 配合
info registers和x/10i $pc查看抛出指令上下文，确认是不是std::bad_alloc、std::logic_error这类可识别类型（gdb 有时能打印异常对象类型）
多线程下 catch throw 不是银弹，真正难的是厘清异常发生时各线程的协同状态——断点只是入口，别停在那一行就以为完事了。
