gdb ./program core-file 启动后直接 bt 即可打印崩溃调用栈，前提是可执行文件与 core 匹配且符号可用；常见问题包括 build id 不一致、缺少 -g 编译信息、调试符号分离未配置 debug-file-directory，以及 ulimit -c 为 0 导致 core 未生成。
gdb ./program core-file 启动后直接 bt 就行
不用额外设置或预加载，只要 gdb 能成功加载可执行文件和 core 文件，进入交互界面后敲 bt 就会立即打印崩溃点的完整调用栈。这是最常用、最直接的方式，前提是两个文件匹配且符号可用。
常见卡点：
-
gdb启动时报not compatible：core 文件和可执行文件的 build ID 或 ABI 不一致，比如程序被 strip 过、或重新编译但没换 core - 启动成功但
bt显示一堆??:?：可执行文件缺少-g编译信息，或调试符号被分离但没用set debug-file-directory指向.debug文件 - 崩溃点显示在
__libc_start_main或start_thread：说明没加载到用户代码栈帧，大概率是 core 文件生成时进程已彻底退出，或线程栈被破坏（多线程场景下更常见）
为什么不能只用 gdb core-file？
单独运行 gdb core-xxx 会报错或无法解析符号——gdb 需要可执行文件提供 ELF 头、段布局、符号表结构才能把 core 里的地址映射回函数名和行号。core 文件本身不包含这些元信息，它只是内存快照。
正确姿势只有两种：
-
gdb ./myapp core-myapp.12345（推荐，一步到位） -
gdb ./myapp→(gdb) core-file core-myapp.12345→(gdb) bt
后者适合你已经进到 gdb 环境、临时想切另一个 core 的情况。
bt full 和 bt 的关键区别在哪
bt 只显示调用栈帧地址、函数名、源码位置；bt full 在此基础上尝试打印每个栈帧的局部变量值。但它依赖两点：
- 当前帧的调试信息必须完整（比如变量未被优化掉，即编译用了
-O0或-O2 -g而非-O3 -g） - core 文件里该帧的栈内存区域没被覆盖（尤其在深度递归或栈溢出后，上层帧可能已损坏）
如果 bt full 某帧显示 Cannot access memory at address 0x...，说明那块栈数据在崩溃时已不可读，别硬试，退回 bt + frame N + info locals 分步查更稳。
容易被忽略的 ulimit 和 core_pattern 陷阱
很多人反复试 gdb 却始终看不到有效 core，其实问题根本不在调试环节——ulimit -c 是 0，或 /proc/sys/kernel/core_pattern 被重定向到无效路径（比如 /dev/null 或权限不足的目录），导致系统压根没生成 core。
确认方法：
- 崩溃后立刻查：
ls -l core*（默认路径）或ls -l /data/coredump/（自定义路径） - 看是否真有文件，且大小 > 0；用
file core-xxx确认输出含ELF core file - 若无文件，回退检查
ulimit -c和core_pattern，不是gdb的问题
线上环境尤其要注意：容器内进程的 ulimit 默认继承宿主机，但很多 Kubernetes Pod 会显式设 securityContext: { runAsUser: xxx }，导致 ulimit -c 被重置为 0 —— 这个细节一漏，后面所有 bt 都白搭。
