bt只显示几行就停在???:?的根本原因是调用栈“断链”，常见于程序或依赖的动态库（如libc.so.6）缺失debug信息或被strip，以及GCC启用-fomit-frame-pointer优化导致帧指针丢失，使GDB无法向上解析栈帧。
为什么 bt 只显示几行就停在 ???:?
根本原因不是GDB坏了，而是调用栈某处“断链”了——gdb 找不到上一帧的起始位置或符号。最常见的是你的程序或它依赖的任意一个动态库（比如 libc.so.6、libpthread.so.0、ld-linux-x86-64.so.2）缺少调试信息或帧指针。
验证方法：
- 运行
readelf -S ./myapp | grep debug，确认有.debug_*节 - 对系统库也查一遍：
readelf -S /lib/x86_64-linux-gnu/libc.so.6 | grep debug，任一为空就可能中断回溯 - 检查是否被
strip过：file ./myapp输出里不应含stripped
-fomit-frame-pointer 导致 backtrace stopped: previous frame identical to this frame
这是 GCC 在 -O2 及以上默认启用的优化，它会让函数不保存 %rbp（x86_64）或 %fp（ARM），GDB 就没法靠帧指针链往上跳。即使你加了 -g，bt 也可能在第 3–5 帧后戛然而止。
必须重编译，且明确指定：
-
-fno-omit-frame-pointer（禁用帧指针省略） -
-O0或最多-O1（-O2会隐式开启-fomit-frame-pointer） - 搭配
-g，三者缺一不可
验证是否生效：反汇编一个函数 objdump -d ./myapp | grep -A5 '<func_name>'</func_name>，看开头是否有 push %rbp; mov %rsp,%rbp。
core dump 回溯时只看到地址，看不到函数名和行号
这通常不是程序本身的问题，而是 gdb 没加载对符号——特别是你用生产环境部署的 stripped 二进制去加载 core，或者没告诉 gdb 去哪找系统库的 debug 包。
操作要点：
- 确保
gdb加载的是带-g编译、未被strip的那个./myapp，不是线上发布的精简版 - 用
set solib-search-path /usr/lib/debug/.build-id/xx/yy指向libc6-dbg安装的 debug 符号路径（Ubuntu/Debian） - 若用
addr2line离线分析，必须用原始带-g的二进制：addr2line -e ./myapp -f -C 0x401234
多线程程序中 bt 只显示当前线程，崩溃点却在别的线程
gdb 默认只展示当前活跃线程的栈，而 C++ 里 std::thread、std::async 或 pthread 创建的线程，崩溃可能发生在任意一个里。你看到的 bt 可能完全无关。
必须主动检查所有线程：
-
info threads查看线程列表 -
thread apply all bt对每个线程执行backtrace - 特别注意状态为
Blocked或Running的线程，它们更可能是肇事者 - 若用
std::async，其线程栈常被封装在std::thread::_State_impl里，需结合frame切换和print查看捕获的异常对象
真正难的从来不是“怎么输命令”，而是你得先意识到：堆栈能不能展开，80% 取决于编译那一刻的选项是否一致，剩下 20% 取决于运行时所有参与模块（包括 libc）有没有提供可解析的展开信息。漏掉任何一个环节，bt 就只是个摆设。
