thread apply all bt是最直接有效的多线程堆栈查看命令，一次性输出所有线程的调用栈并按thread 1、thread 2等标识分组；加-q可屏蔽冗余切换提示，提升排查效率。
thread apply all bt 是最直接有效的命令
不用进交互模式、不需手动切线程，thread apply all bt 一条命令就能把每个线程的调用栈全打出来。它会按线程 ID 分组输出，每段开头标清楚 Thread 1、Thread 2 这类标识，避免你漏看或混淆。
常见误区是只输 bt ——那只会显示当前默认线程（通常是主线程）的栈，而真正出问题的可能是第 7 个 worker 线程，根本不会被看到。
加 -q 参数避免冗余提示干扰阅读
线程一多，thread apply all bt 默认会在每个线程切换时打印类似 [Switching to thread 3 (Thread 0x7ffff7587700 (LWP 12346))] 的提示，占屏又无信息量。实际排查时栈本身已经很长，这些提示反而掩盖关键帧。
用 thread apply all -q bt 就能安静输出，只留纯栈内容。这是生产环境快速扫视几十个线程时的必备习惯。
-
-q不影响任何调试信息，只是关掉切换提示 - 如果连
bt都没输出，说明 core 文件和可执行文件不匹配，或符号缺失，先别急着查栈 - 输出里出现大量
??或地址如0x00007f...而非函数名，基本可判定没带-g编译或被strip过
bt full 和 info locals 要谨慎搭配使用
bt full 会把每个栈帧的局部变量也打出来，看着很全，但代价明显：输出体积可能暴涨 5–10 倍，尤其当某帧里有大数组、string 或 vector 时。你本来想快速定位崩溃点，结果卡在滚动几百行变量值里。
更实用的做法是先用 thread apply all -q bt 扫一遍，找到可疑线程（比如栈顶是 __memcpy_ssse3 或某空指针解引用），再单独 thread 3 切过去，针对性执行 bt full 或 info locals。
- 多线程下
thread apply all "bt full; info locals"几乎总是过度输出 - 某些优化后的 Release 版本，
bt full可能因寄存器复用导致变量值不可靠，别盲目信任 - 若某线程栈显示深度异常（如连续几百层
func→func），优先怀疑栈溢出，此时bt full没意义，该看info registers里的rsp
core 文件必须匹配且含调试符号，否则栈就是废的
再熟练的命令也救不了一个“假 core”：gdb ./a.out core-12345 成功进入 GDB，不代表你能看到有效栈。常见失效场景：
- 可执行文件编译时没加
-g，或上线前被strip掉符号 →bt显示全是?? - core 是旧版本程序崩出来的，而你拿新版本可执行文件去加载 → 提示
not compatible - core 文件被截断或磁盘写入失败（尤其容器里
/tmp空间不足）→file core-12345可能报 “data” 而非 “ELF core file”
验证是否靠谱，进 gdb 后第一句就敲 info proc mappings：如果连进程内存布局都读不出来，后面所有 bt 都是空中楼阁。
