调试多线程回调崩溃需先确保编译含调试符号（-g -O0，禁用strip），gdb中用thread apply all bt检查各线程栈，重点排查对象提前析构导致的this野指针问题，并用shared_ptr延长生命周期。
崩溃时没调用栈？先确认是否启用了调试符号
多线程回调里崩溃却看不到有效调用栈，大概率是编译时没带调试信息，或者崩溃发生在信号处理上下文（比如 std::terminate 或 abort）里，导致栈帧被截断。Linux 下用 gdb 附加运行中进程前，得确保二进制文件包含 .debug_* 段。
- 编译时加
-g -O0（开发阶段别用-O2，内联会抹掉帧指针） - 链接时别加
-s或--strip-all - 若用 CMake，确认
CMAKE_BUILD_TYPE是Debug，不是RelWithDebInfo—— 后者在某些优化下仍会丢帧
gdb 里怎么抓到真正崩溃的线程？
默认 gdb 只停在触发 signal 的线程，但崩溃源头往往在别的线程——比如回调里访问了已被主线程释放的对象。必须让 gdb 在所有线程都停下，并逐个检查。
- 启动后执行
thread apply all bt，看每个线程的栈 - 用
info threads找出状态为running或segfault的线程 ID，再thread <id>切过去 - 如果崩溃瞬间太快，加
handle SIGSEGV stop print让 gdb 捕获段错误信号 - 对
std::thread回调，注意栈顶可能是__pthread_start或std::thread::_State::~_State，真函数在它下面几层
回调里访问 this 指针崩溃？大概率对象已析构
这是最常见原因：主线程 delete 了对象，但 worker 线程还在执行它的成员函数回调。this 变成野指针，gdb 里看到的调用栈顶层可能只是 operator()<> 或 std::invoke，真实崩溃点藏在第二三级。
- 用
valgrind --tool=helgrind检查数据竞争，它能报出“lock-order-inversion”或“potential data race on <addr>” - 把回调改成
std::shared_ptr<T>捕获，确保对象生命周期覆盖整个回调执行期 - 避免裸指针传入线程：不要
std::thread(&A::cb, a_ptr)，改用std::thread([ptr = std::shared_ptr<A>(a_ptr)]{ ptr->cb(); }) -
gdb中用print *(A*)this看内存是否全零或乱码，确认是否已析构
Windows 上用 Visual Studio 调试回调崩溃
VS 的“仅我的代码”默认关掉非用户帧，导致回调栈只显示 thread_start<unsigned int></unsigned> 这种包装器。必须手动打开原生调试并禁用过滤。
立即学习“C++免费学习笔记（深入）”；
- 项目属性 → 配置属性 → C/C++ → 常规 → “调试信息格式” 设为
Program Database (/Zi) - 调试 → 选项 → 调试 → 常规 → 取消勾选“启用仅我的代码”
- 崩溃时按
Ctrl+Alt+E，勾选Win32 Exceptions和C++ Exceptions - 调用栈窗口右键 → “切换到未加载的符号”（尤其当看到
[External Code]占满屏幕时）
复杂点在于：回调可能跨 DLL 边界，或由第三方库（如 libuv、Boost.Asio）调度，这时得确认对应 DLL 是否加载了 PDB，否则栈帧还是断的。
