能还原，但必须满足三个硬性条件：有匹配的未strip可执行文件、core文件完整、调试符号存在（-g编译）；缺一不可，否则bt只能显示地址而无函数名和行号。
能还原，但必须满足三个硬性条件：有匹配的未 strip 的可执行文件、core 文件完整、调试符号存在（-g 编译）。缺一不可，否则 bt 只能显示地址，看不到函数名和行号。
确认 core 文件是否真包含可用现场
不是所有 “core” 都是有效现场。常见假象包括：
- core 文件大小为 0 或几 KB → 实际没生成成功，
ulimit -c仍为 0 或/proc/sys/kernel/core_pattern被重定向到|/usr/lib/systemd/systemd-coredump且服务异常 - core 文件存在但
file core*显示 “data” 而非 “core file” → 可能是日志误命名，或容器中被截断 - 用
gdb /path/to/binary core后执行bt报错No stack.或只显示#0 0x0000... in ?? ()→ 符号缺失或二进制不匹配
验证命令：readelf -n core | grep -A2 "NT_PRSTATUS" 应输出寄存器快照；file core 应含 “core file” 字样。
加载 core 后第一件事不是看 bt，而是检查信号和线程
崩溃信号决定分析路径：SIGSEGV 和 SIGABRT 的根因逻辑完全不同，跳过这步容易误判。
- 执行
info signals查看崩溃时触发的信号（如SIGSEGV），再对照信号表判断性质 - 执行
info threads看是否多线程环境；若崩溃线程不是主线程，需先thread N切换过去再bt - 对
SIGABRT（常见于malloc(): corrupted top size），bt显示的是“检测点”，不是“破坏点”，得结合info registers和x/20xg $rsp看栈内容是否已被覆写
还原变量和内存状态的关键命令组合
仅靠 bt 只能看到调用链，真正定位 bug 得深入上下文：
- 在崩溃帧执行
frame确认当前栈帧，再用info locals查看局部变量值（注意：优化编译（-O2）可能让变量被优化掉） - 用
print *(int*)0x7f8e4c0008c0检查疑似野指针地址是否可读（若报Cannot access memory，基本确认为空或已释放） - 对疑似越界写，用
x/16xb &buf查看缓冲区前后字节，找异常填充（如0xdeadbeef或重复 0x00） - 若怀疑堆损坏，加载
libc符号后执行heap（需glibc调试包）或malloc_stats()手动打印堆状态
容易被忽略的兼容性陷阱
生产环境最常踩坑的不是命令不会用，而是环境错配：
- core 文件由 glibc 2.33 生成，但本地 gdb 加载的是 2.28 的
libc.so.6→bt可能中断在__libc_start_main就停住，需用set sysroot /path/to/matching/libc - 程序用
musl编译（Alpine 容器常见），而本地是 glibc 环境 →gdb无法解析符号，必须用对应工具链的gdb-musl - core 文件来自 ARM64 机器，但在 x86_64 主机上直接运行
gdb→ 会提示架构不匹配，需用gdb-multiarch并指定set architecture aarch64
真实崩溃现场从不自动对齐你的本地环境，匹配二进制、库、架构、glibc 版本，比记住 bt 命令重要十倍。
