thread apply all bt 可能卡住或输出不全，需确认 gdb 版本≥7.0、进程处于中断态；加 -q 抑制提示信息，用 set logging 重定向长输出；_lll_lock_wait 等不等于死锁，须查锁归属与环形依赖；bt full 需写为 "bt full; info locals"。
thread apply all bt 会卡住或输出不全？先确认 GDB 版本和线程状态
低于 gdb 7.0 的版本不支持可靠多线程调试，thread apply all bt 可能直接报错或只显示主线程。运行 gdb --version 确认版本；若为 6.x，必须升级。另外，如果进程已崩溃（如收到 SIGSEGV）但未进入 gdb 中断态，需先用 gdb -p PID 或加载 core 文件再执行该命令。
输出太长看不清？用 -q 和日志重定向控制噪音
默认输出每切换一个线程都会打印类似 [Switching to thread 2 (Thread 0x7ffff7587700 (LWP 12346))] 的提示行，干扰关键堆栈。加 -q 参数可抑制：
thread apply all -q bt
若线程数超 20，建议导出到文件分析：
set logging file threads_bt.logset logging onthread apply all -q btset logging off
注意：set logging on 后所有 GDB 输出（包括错误提示）都会写入文件，别忘了关掉。
看到一堆 _lll_lock_wait 或 pthread_cond_wait 就是死锁？不一定
这类函数出现在堆栈顶部，只说明线程在等锁或条件变量，并不等于死锁。真正要判断，得交叉验证：
- 找出阻塞在线程 A 持有的锁上的线程 B，再看线程 B 是否反过来等线程 A 持的另一把锁（环形依赖）
- 用
print mutex_name查__m_owner字段，转成十进制就是 LWP ID；再回thread apply all -q bt日志里找对应 LWP 的堆栈 - 若某锁的
__m_owner是负数或0x0，大概率是未初始化或已销毁的互斥体，不是死锁而是使用错误
别只盯着 bt 输出里的“wait”，得结合锁归属和代码逻辑一起读。
想看局部变量或寄存器？别直接 thread apply all bt full
bt full 不是原子命令，GDB 会把它当两个词解析，报错 Undefined command: "full"。正确写法必须用双引号包裹组合命令：
thread apply all "bt full; info locals"
但要注意：info locals 在优化编译（-O2）下可能为空；bt full 本身也会显著拖慢响应——尤其线程多、栈深时。生产环境排查优先用 thread apply all -q bt 快速定位可疑线程，再单独 thread N 切入深入查。
