死锁线索可通过thread apply all bt输出中多个线程栈顶均停在pthread_mutex_lock、__lll_lock_wait或futex_wait等阻塞调用识别，若彼此持有对方所需锁且__m_owner字段显示交叉占用，则确认为死锁。
thread apply all bt 输出里怎么看死锁线索
直接看栈顶函数是不是 pthread_mutex_lock、__lll_lock_wait 或 futex_wait 这类阻塞调用。如果多个线程都卡在锁等待上，且各自持有的锁又被对方需要，就极可能是死锁。
常见错误现象：所有线程堆栈末尾都停在类似 __lll_lock_wait 或 sem_wait，没有继续往下走的用户代码；或者两个线程分别卡在 mutex1 和 mutex2 的加锁处，而彼此已持有一个锁。
- 重点对比各线程栈中锁变量名（如
AccountA_mutex）和__m_owner字段值，它指向持有该锁的线程 LWP ID - 用
print 0x2527把十六进制 owner 地址转成十进制 PID，再对照info threads输出找对应线程 - 注意：
__m_owner是 glibc 内部字段，不同版本可能叫__owner或结构体偏移不同，别硬记字段名，用ptype查类型更稳
为什么 thread apply all bt 有时看不到完整调用链
因为编译时没加 -g 或用了 -O2 以上优化，导致调试信息丢失或内联展开，栈帧被裁剪。GDB 就只能显示寄存器状态或不带符号的地址。
使用场景：线上进程 attach 后发现一堆 #0 0x00007f... in ?? ()，基本可以判定是编译问题，不是运行时异常。
- 必须用
-g -Og编译，-Og在保留调试体验的同时做轻量优化，比-O0更接近真实运行环境 -
-pthread不只是链接选项，它还影响 glibc 对线程的调试支持，漏掉会导致info threads显示不全 - 若已上线无调试符号，可尝试用
gcore生成 core 文件，再用带符号的二进制gdb ./a.out core.xxx加载分析
thread apply all bt 和 pstack 输出差异在哪
thread apply all bt 是 GDB 命令，在调试会话中执行，能结合符号、变量、源码行号；pstack 是独立工具，只读取内存快照，输出纯调用栈，不依赖调试符号，但也没法查锁状态或变量值。
性能 / 兼容性影响：对高负载进程，pstack 几乎无侵入，gdb attach 可能短暂暂停所有线程；但 thread apply all bt 能看到更多上下文，比如哪个线程刚释放了锁、哪个正在 wait_cond。
-
pstack输出里看不到锁 owner，没法判断谁占着资源；gdb下可用print mutex_name直接查 -
thread apply all bt默认只打主线程栈，必须显式加all，漏写就会误判为单线程卡死 - 某些容器环境（如 rootless pod）里
gdb attach权限受限，pstack更容易跑通
怎么把 thread apply all bt 结果导出到文件
别用重定向，GDB 的输出控制是内部机制，直接 > file.txt 会失败或内容不全。
正确做法是用 GDB 自带的日志开关：
set logging file gdb_bt.logset logging onthread apply all btset logging off
导出后记得检查文件是否为空——如果进程已退出或 GDB 没 attach 成功，日志里只会写 “No stack.”。另外，thread apply all bt 在某些老版本 GDB（如 6.3）下不支持，必须确认 gdb --version ≥ 7.0。
真正麻烦的是锁嵌套深、线程数超百的场景：输出太长，grep 不好定位。这时候要配合 thread apply ID bt 单独看可疑线程，而不是盲目扫全量。
