线程销毁过程不可调试，只能在销毁前最后一刻干预；需在pthread_exit、函数return或std::thread析构前设断点，而非依赖底层符号，否则GDB无法获取有效上下文。
线程销毁过程本身不可调试——因为销毁完成后栈已回收、寄存器失效、GDB 失去上下文。你真正能干预的，只有“销毁前最后一刻”。必须把断点设在 pthread_exit、函数 return、或 std::thread 析构触发的底层退出路径上，否则 bt 一定为空或全是 ??。
为什么 info threads 显示 (exited) 后就什么都做不了
当 info threads 输出某行末尾是 (exited)，说明该线程的内核资源（栈、TLS、LWP）已被回收，GDB 无法切换过去，thread <n> 会报错 “Thread ID not known”。这不是 GDB 的限制，而是 Linux 进程模型决定的：线程终止后，其用户态上下文即被内核释放。
此时你看到的只是“尸体登记表”，不是现场。想查它怎么死的，只能靠外部线索：
- 提前在所有可能的退出点插日志，比如
write(STDERR_FILENO, "tid=0x%lx exit at line %d\n", pthread_self(), __LINE__) - 用
strace -e trace=exit_group,exit -p <PID>捕获系统调用级退出事件（注意：exit_group是线程组退出，exit是单线程退出） - 若线程因异常退出，用
catch throw或handle SIGABRT stop拦截，而不是等它彻底消失
如何在 pthread_exit 前准确打断点
pthread_exit 是线程退出的“正门”，但直接 break pthread_exit 往往太晚——GDB 在进入该函数时，栈可能已开始解构。更可靠的做法是：在你自己的线程函数末尾、或显式调用 pthread_exit 前一行下断点。
立即学习“C++免费学习笔记（深入）”；
例如，对如下函数：
void worker() {
do_work();
cleanup(); // ← 在这一行设断点，比 break pthread_exit 更早
pthread_exit(nullptr);
}
如果线程是隐式 return 退出（如 std::thread 绑定的 lambda），则断点必须打在函数最后一行 } 前，或者用 finish 从函数内部单步到返回点。
关键差异：
-
break pthread_exit：断在 libc 内部，栈帧可能已不完整 -
break worker:25（假设第 25 行是return或pthread_exit调用）：断在你可控的代码位置，寄存器和局部变量全在 - 对 C++ 线程，还要注意
std::thread析构时若未join/detach，会调用std::terminate→ 此时应catch throw或handle SIGABRT stop
set scheduler-locking on 会让线程“假活”
开启 set scheduler-locking on 后，你单步或继续时，其他线程被冻结。这时线程看似正常退出，关掉锁却立刻静默崩溃——这几乎肯定是竞态：比如 A 线程正在访问某对象，B 线程已在别处把它 delete 掉，而调度锁掩盖了释放时机。
验证方法：
- 先关掉
scheduler-locking，用thread apply all bt抓一次全量栈，看是否有线程卡在malloc、free或锁操作上 - 用
watch *(int*)0xdeadbeef监控疑似被释放的内存地址（需先用info proc mappings确认地址可读） - 对共享对象加引用计数或使用
std::shared_ptr，并在析构函数打日志，确认销毁时机是否早于使用
线程销毁调试最易忽略的一点：你永远看不到“销毁中”的状态，只能捕获“即将销毁”。所有技巧都围绕一个目标——把断点打得足够早、足够靠近你写的代码，远离 libc 和内核的黑盒路径。一旦依赖 pthread_exit 或 exit_group 这类底层符号，你就已经慢了一拍。
