thread apply all bt 是快照式批量打印所有线程调用栈的命令，不切换当前线程，按线程 ID 顺序输出，适用于快速定位死锁或竞态卡点，配合 -v、set pagination off 及 info threads 可提升调试效率。
怎么用 thread apply all bt 查所有线程的调用栈
这条命令本质是批量执行 bt（backtrace）到每个线程上，不是“切换”，而是“快照式查看”。它会按线程 ID 顺序逐个打印调用栈，中间不暂停、不交互。如果你在调试死锁或竞态，这是第一眼定位哪几个线程卡在哪的最快方式。
常见错误是误以为执行后会自动跳转到某个线程——不会。thread apply all bt 运行完，GDB 当前线程仍是原来那个（info threads 可确认）。想切过去，得手动 thread N。
- 加
-v参数（thread apply all bt -v）能看到更全的寄存器和帧信息，适合分析信号处理或内联函数问题 - 如果输出太长刷屏，可先
set pagination off，避免卡在“--more--” - 部分旧版 GDB（如 7.2 之前）不支持
-v，直接报错，换用thread apply all info registers分开查
如何只看特定线程、或者过滤掉空闲线程
Linux 下的 pthread 很多会创建等待型线程（比如 __pthread_cond_wait 或 epoll_wait），它们的栈基本没用。盲目扫 all bt 容易淹没关键线索。
实用做法是先 info threads 找出疑似活跃的线程 ID（看 PC 是否停在你的代码里、或是否在 mutex/cond 等同步点），再针对性查：
立即学习“C++免费学习笔记（深入）”；
-
thread 3切到线程 3，然后bt—— 最常用 -
thread apply 2 5 7 bt同时查多个指定线程（注意空格分隔，不能写成2,5,7） - 想跳过所有阻塞在
futex的线程？暂时没内置过滤，但可以thread apply all bt | grep -A 5 "your_function_name"配合 shell 管道快速定位（需 GDB 输出未被截断）
为什么 thread apply all bt 有时卡住或报 “Cannot find bounds of current function”
这不是命令本身的问题，而是当前线程处于栈损坏、符号缺失、或刚收到信号（如 SIGSTOP）但上下文未就绪的状态。GDB 尝试解析栈帧失败时就会卡住或报这类警告。
典型场景包括：线程正在做 longjmp、刚崩溃进 signal handler、或用了 -fomit-frame-pointer 编译且没带 debug info。
- 先试
info registers看rsp/rbp（x86_64）是否明显异常（比如为 0 或超大值） - 确认二进制带调试信息：
file your_program输出里要有 “symbols found”；否则gdb -q -ex "set debug infcall 1" -ex "thread apply all bt" ./a.out能暴露更多底层失败原因 - 若某线程反复报错，可用
thread N切过去，再frame 0+info frame看 GDB 认为的当前帧是否合理
切换线程后，变量名补全和 print 为什么还显示老线程的值
GDB 的表达式求值（print、display、tab 补全）默认作用于当前线程的栈帧，但符号表是全局加载的。所以你切到线程 5 后 print my_var，GDB 会尝试从线程 5 的栈里找 my_var 的地址——如果该变量是局部变量且线程 5 没进过对应函数，就会报 “no symbol in current context”。
容易忽略的是：全局/静态变量能正常 print，但局部变量必须确保当前帧（frame）属于定义它的函数。一个常见陷阱是切线程后没手动 up/down 到正确帧，结果 print 的是寄存器值或随机内存。
- 每次
thread N后，顺手敲bt确认当前帧位置 - 用
info proc mappings可验证各线程的栈地址范围是否重叠（多线程栈通常不重叠，重叠大概率已损坏） - 如果要跨线程比较同一局部变量，只能靠
print *(type*)address手动算地址——没有捷径
