gdb 可在崩溃瞬间中断并定位线程与栈帧：运行后执行 info threads 查挂起线程，thread apply all bt 查所有栈，结合 thread <n> bt full 和局部变量分析悬垂指针、对象生命周期错配等多线程段错误根源。
用 gdb 直接定位崩溃时的线程和栈帧
Segmentation fault 发生时，程序已处于非法内存访问状态，但只要没被信号 handler 捕获或屏蔽，gdb 就能停在出错那一行。关键不是“事后分析 core”，而是让 gdb 在 crash 瞬间中断。
- 启动时加
-g编译，确保符号信息完整：g++ -g -pthread main.cpp - 用 gdb 运行：
gdb ./a.out，然后输入run；崩溃后立刻执行info threads看哪个线程挂了，再用thread apply all bt查所有线程栈 - 特别注意：如果主线程没崩，但某个
std::thread或pthread崩了，bt可能只显示clone或start_thread—— 这说明栈已损坏或线程函数早已 return，此时要结合thread <n> bt full和局部变量检查
常见多线程段错误源头：悬垂指针与提前释放
最典型的不是锁问题，而是对象生命周期和线程执行节奏不匹配。比如 lambda 捕获了局部变量地址，或 std::thread 被 move 后原对象析构，但新线程还在读写它。
- 检查所有
std::thread构造时的参数：是否传入了局部对象的this、引用或指针？例如std::thread{&MyClass::work, this}安全的前提是this对象在整个线程运行期间有效 - 避免
std::thread的隐式 detach：未join()或detach()就析构会调用std::terminate()，但某些环境下表现为段错误（尤其 ASan 未启用时） - 用
std::shared_ptr管理跨线程共享对象，并在 lambda 中捕获shared_ptr而非原始指针，可大幅降低悬垂风险
用 AddressSanitizer（ASan）抓内存越界和 UAF
gdb 只告诉你“哪一行崩了”，但 ASan 能告诉你“为什么崩”——比如堆上 use-after-free、栈上缓冲区溢出、释放后仍被另一线程读取。
- 编译加
-fsanitize=address -fno-omit-frame-pointer -g，链接也要带-fsanitize=address - 运行时报错会直接标出：分配位置、释放位置、非法访问位置，以及所有相关线程的调用栈。例如看到
heap-use-after-free on address 0x… by thread T2，就能确认是 T2 在 T1 释放后继续用了那块内存 - 注意：ASan 默认禁用部分优化，且线程检测有一定开销；若怀疑 false positive，可加
-shared-libsan并确保运行时环境有对应 sanitizer runtime
检查 std::mutex 和 RAII 使用是否真正覆盖临界区
段错误有时是“症状”，根源是数据竞争导致对象被破坏（比如 vtable 指针被覆写），进而调用虚函数时跳转到非法地址。
立即学习“C++免费学习笔记（深入）”；
- 确认
std::mutex不是定义在线程函数内部（否则每个线程一把锁，毫无保护作用） - 检查是否用了
std::lock_guard但忘了加std::defer_lock？比如std::lock_guard<std::mutex>(m)会立即 lock，而std::unique_lock才支持延迟锁定 - 警惕“锁住 A 再锁 B”引发死锁后线程卡住，其他线程持续写入未受保护的成员 —— 表面看是段错误，实则是数据竞争积累后的必然崩溃
多线程段错误最难复现的往往不是 bug 本身，而是触发条件：它依赖内存布局、调度顺序、缓存一致性。所以别只靠单次 gdb，要把 ASan + 线程 sanitizer（-fsanitize=thread）一起开，哪怕慢十倍，也比靠猜强。
