必须用-g编译才能加载符号并查看完整堆栈，否则bt只显示???:?或0x... in ??()；正确编译为g++ -O0 -g -o myapp main.cpp，用file或readelf验证.debug_*节存在。
gdb 启动时如何加载符号并确保能查看堆栈
必须用 -g 编译，否则 gdb 看不到函数名、行号和局部变量。没有调试信息时，bt 只显示 ??:? 或 0x... in ?? ()，基本无法定位。
- 正确编译：
g++ -g -o myapp main.cpp - 如果用了优化（如
-O2），即使加了-g，内联函数可能被展开、帧指针可能被省略，导致bt不完整；调试阶段建议用-O0 -g - 确认二进制含调试信息：
file myapp应输出包含with debug_info；或运行readelf -S myapp | grep debug看是否有.debug_*节
程序崩溃后怎么拿到完整的 backtrace
崩溃通常由信号触发（如 SIGSEGV），gdb 能自动停在出问题的那一帧。关键不是“怎么打印”，而是“停在哪、怎么看全”。
- 直接运行：
gdb ./myapp→run→ 崩溃后立刻输入bt（即backtrace） - 如果崩溃太快或想复现特定状态，可先
run arg1 arg2，再用Ctrl+C中断，然后bt -
bt默认只显示最上层几帧；要全部展开，用bt full（显示变量值）或bt 20（显示最多 20 帧） - 注意：若某帧显示
(inlined function)，说明该函数被内联，实际调用位置可能藏在上一帧的源码行里
core dump 文件怎么配合 gdb 分析堆栈
线上程序常配置生成 core 文件，但直接 gdb ./myapp core 很容易因路径/库缺失看不到源码或符号。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 先确认
core对应的是哪个二进制：file core会提示 “from ‘./myapp’” - 确保
gdb加载的是带-g的那个myapp，而不是生产环境部署的 stripped 版本 - 如果依赖动态库（如
libboost.so），用set solib-search-path /path/to/libs告诉gdb去哪找符号 - 运行
bt前，先info registers和x/10i $pc看崩溃点附近汇编，有时比源码更可靠
为什么 bt 显示 #0 0x0000… in ?? ()，怎么修
这不是 gdb 坏了，是符号链断了。常见于调用栈跨了不同构建环境的模块（比如插件、第三方 SDK、静态链接的 libc）。
立即学习“C++免费学习笔记（深入）”；
- 检查是否在
bt之前执行过strip myapp—— 这会删掉所有调试符号，不可逆 - 若调用栈进入系统库（如
libc），默认不带源码；可装libc6-dbg（Ubuntu/Debian）或glibc-debuginfo（CentOS/RHEL） - 对
std::thread或async创建的栈，gdb可能无法自动关联到用户代码；需结合info threads+thread apply all bt查所有线程 - 某些嵌入式或裁剪版 libc（如 musl）不提供调试符号，
??就是真的没法解析
堆栈能不能看明白，80% 取决于编译时有没有 -g 和运行时有没有匹配的二进制。别等 crash 了才想起没开调试信息。
