GDB分析core-dump本质是加载崩溃“内存快照”与带调试符号的可执行文件，还原调用栈、变量及寄存器状态；需确保core文件为ELF格式、程序名/PID匹配、可执行文件含-g编译信息，否则会提示“no debugging symbols”或“not compatible”。
用 GDB 分析 core-dump 文件，本质是让调试器加载崩溃时的“内存快照”和对应的可执行文件，还原出崩溃瞬间的调用栈、变量值和寄存器状态。关键前提是：你得有带调试符号（debug info）的可执行文件，以及一个有效生成的 core 文件。
确认 core 文件是否有效且匹配
core 文件不是万能的，它必须和崩溃时运行的程序完全对应：
- 用 file core-xxx 查看文件类型，确认是 ELF core file；
- 用 readelf -n core-xxx | grep -A2 "NT_PRPSINFO" 提取程序名和 PID，核对是否与预期崩溃进程一致；
- 用 gdb ./your_program core-xxx 启动后，若提示 “not compatible” 或 “no debugging symbols”，说明可执行文件被 strip 过、版本不匹配，或未编译带 -g；
- 若 gdb 进入后显示 (no debugging symbols found)，堆栈可能只显示 ??:?，无法定位到源码行——此时需重新编译带调试信息的版本再分析。
快速获取全量调用栈（bt）与关键帧细节
进入 gdb 后第一件事就是看崩溃点在哪：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 输入 bt（backtrace），显示完整调用栈，从最内层（#0）崩溃位置开始向上展开；
- 加 bt full 可同时打印各栈帧的局部变量值（前提是符号可用）；
- 用 frame N 切换到第 N 帧（如 frame 0），再用 info registers 查看当时 CPU 寄存器状态（尤其关注 rip、rsp、rdi、rsi 等）；
- 用 list 显示当前帧附近源码；用 print 变量名 查看具体值，比如 print ptr 可验证是否为空指针。
定位典型崩溃原因的实用线索
不同崩溃模式在栈和寄存器中留下的痕迹不同，可针对性排查：
- 段错误（SIGSEGV）：查看 bt 中最顶层帧的指令地址（如 #0 0x000055... in main ...），再用 x/10i $rip 反汇编崩溃指令，结合 print/x $rdi 看访问地址是否为 0、非法或已释放内存；
- 栈溢出：bt 显示极深的递归帧（如几百层同名函数），或 info registers 中 rsp 异常靠近栈底（如 0x7fff0000xxxx），配合 info proc mappings 查看栈段范围；
- 野指针/释放后使用：bt 正常但某变量值明显异常（如 this=0xdeadbeef），用 info proc mappings 查该地址是否落在已 unmapped 区域；
- 多线程问题：用 info threads 列出所有线程，thread apply all bt 查全部线程栈，对比哪些线程卡在锁、条件变量或内存操作上。
进阶技巧：关联符号与源码路径
如果源码不在默认路径，或调试文件分离存放，GDB 可能找不到 .c 文件：
- 用 set substitute-path /old/path /new/path 重定向源码路径；
- 若调试信息在单独的 debuginfo 包中（如 CentOS 的 debuginfo-install），用 set debug-file-directory /usr/lib/debug 指定目录；
- 用 show debug-file-directory 和 show directories 确认路径是否生效；
- 崩溃涉及 so 动态库时，确保对应 .so 文件存在且含调试符号，否则其内部帧仍会显示为 ??。
