bt显示全是?主要有两种原因：一是程序被strip删除了调试信息，可用file和readelf验证；二是栈帧被破坏，需通过寄存器和内存手动回溯调用链。
直接说结论：bt 显示全是 ?，基本就两种可能——栈帧被破坏，或者调试信息被删了。前者是程序 bug 导致的，后者是编译/发布流程搞的鬼。
检查是否被 strip 过
这是最容易忽略、也最容易验证的一点。很多嵌入式或线上部署环境会用 arm-linux-strip 或 strip 清除符号表来减小体积，结果就是 gdb 看不到函数名、行号，bt 只剩问号。
- 用
file your_program查看是否含 “not stripped” 字样；不含？大概率被 strip 了 - 用
readelf -S your_program | grep debug或nm -C your_program | head -5看有没有调试符号或函数名输出 - 临时补救：如果源码还在，重新用
g++ -g编译，别加strip步骤
确认栈是否被破坏
如果确认没 strip（file 输出带 not stripped，nm 能看到符号），但 bt 还是问号，那几乎可以断定栈被踩坏了——比如野指针写栈、越界拷贝、重复 free 局部变量地址等。
- 典型现象：只有崩溃线程的栈是
?，其他线程能正常显示 - 关键线索在寄存器：
p $rbp和p $rsp（x86_64）或p $ebp/p $esp（x86）能告诉你当前栈底和栈顶位置 - 用
x/10ag $rbp向上翻几层栈内存，找连续的、看起来像返回地址的值（比如落在.text段范围内的地址） - 再用
info symbol 0x400673（把地址代进去）反查这个地址属于哪个函数
用 frame 手动回溯调用链
当 bt 失效，frame 命令就成了救命稻草。它不依赖完整调用链推导，而是靠寄存器和内存里残留的帧指针链手动跳转。
-
info registers rbp rsp先看当前帧指针和栈指针 -
x/2gx $rbp查看$rbp指向的两个值：第一个通常是上一级$rbp，第二个是返回地址 -
frame 0x7fffffffe010（把上一级$rbp值代入）可强行切到上一帧 - 切过去后用
info frame确认当前帧结构是否合理（比如saved rip是否指向合法代码段）
为什么不能只靠 bt full 或 bt 10 解决
bt full 本质还是依赖栈帧链自动遍历，一旦某一级 $rbp 被覆盖成非法值（比如 0x0、0xffffffff、或堆地址），遍历就中断，后面全变成 ?。这不是命令没用，而是底层数据已经不可信了。
真正有效的做法是：先用寄存器和原始内存定位到还能识别的最深一层，再逐帧向上手工还原。这个过程没法自动化，但比加日志重跑几十次快得多——尤其对偶发 core、复现困难的问题。
