线程退出时栈帧丢失导致bt为空或仅显示??，根本原因是线程已终止、栈内存被回收；必须在线程即将退出但栈尚未销毁的瞬间干预，如在pthread_exit/return前设断点、拦截信号、捕获系统调用或启用线程退出日志。
线程退出时没留下栈帧，bt 为空或只显示 ??
这是最典型的线程退出问题现象：程序疑似某线程异常终止，但用 gdb 附加后执行 bt，发现当前线程栈完全丢失，或者只看到 ?? 和零散寄存器值。根本原因是线程已退出，其栈内存被回收，GDB 无法还原调用链。
真正能抓到有效现场的时机，只在线程**即将退出但尚未销毁栈**的瞬间。所以不能等崩溃后再 attach，必须提前干预：
- 在疑似退出点（比如
pthread_exit前、return前、或exit()调用前）加一个临时断点，配合finish或单步，卡在栈还完整的位置 - 若线程是因未捕获异常（C++）或
sigsegv等信号退出，需先用handle SIGUSR1 stop print类命令让 GDB 拦截对应信号，避免被系统直接终止 - 对 pthread 线程，可考虑在
pthread_create返回后立刻对新线程设条件断点：break worker_function thread 2 if tid == expected_tid，缩小干扰范围
info threads 显示线程状态为 exited，但你想知道它怎么退出的
info threads 中看到某线程 ID 后缀是 (exited)，说明它已结束，GDB 不再能切换过去调试。这时候光看列表毫无意义——你需要的是“退出前最后一刻”发生了什么。
可行路径只有两条：
- 启用线程退出日志：在代码中，于每个可能的退出路径（包括
pthread_exit、return、exit、abort）前插入write(STDERR_FILENO, "thread 0x..., exiting at line XXX\n", ...)，配合strace -e trace=write -p PID捕获输出，快速定位退出点 - 用
catch syscall exit_group（Linux）或catch syscall exit捕获线程级退出系统调用。注意：这不是 catch 所有线程退出，而是 catch 整个进程组退出；若只想监控某线程，得结合thread apply all catch syscall exit（部分 GDB 版本支持），或改用catch throw（C++ 异常）
线程静默退出，set scheduler-locking on 反而让问题消失
开启 set scheduler-locking on 后，其他线程被冻结，你单步调试主线程或目标线程时一切正常，但一关掉就复现退出——这几乎肯定说明存在竞态：比如某线程在读写共享结构体时，另一线程已把它 free 掉，而你冻结调度后掩盖了释放时机。
此时不能依赖单步，要转向数据观测：
- 对可疑指针加
watch *ptr，观察谁修改/清空了它；注意 watchpoint 会显著拖慢运行，只在关键变量上设 - 用
thread apply all bt在 crash 前一刻批量抓所有线程栈（需提前在稳定点触发，比如某个全局计数器达到阈值时） - 检查是否漏了
pthread_join：未 join 的分离线程（detached）退出后资源立即回收，GDB 来不及反应；确认创建时是否误用了PTHREAD_CREATE_DETACHED，或忘了调pthread_detach
多进程场景下，子进程里的线程退出了，但 GDB 默认不跟过去
如果你的主程序 fork 出子进程，子进程再创建线程，而 bug 出在子进程的某个线程里，gdb ./main 默认只调试父进程，子进程线程根本不会出现在 info threads 里。
必须显式告诉 GDB 关注子进程：
- 启动时用
gdb -p $(pidof binary2)直接 attach 到子进程 PID（前提是你知道 binary2 启动后 PID） - 或在父进程中提前设置：
set follow-fork-mode child，这样run后 GDB 自动切到子进程上下文 - 若子进程已运行，用
add-inferior+inferior 2+attach 1234手动添加子进程 inferiors；之后info inferiors和thread apply all bt才能覆盖全部上下文
线程退出问题最难的从来不是“怎么打印栈”，而是“怎么让栈别丢得太快”。所有技巧都围绕一个核心：把观测点尽可能往前移——移到栈还在、变量未失效、信号未投递的那个精确指令周期。
