崩溃前路径靠core文件还原现场，而非回放；需满足-g编译、ulimit -c unlimited、core_pattern可达且有写权限三条件，否则bt截断或报no stack。
崩溃前路径不是“回放”，而是靠 core 文件还原现场
GDB 本身不能倒带执行历史，所谓“调试崩溃前的运行路径”，实际是通过 core 文件 + 原始可执行文件，重建崩溃那一刻的完整内存与调用状态。关键不在于“怎么往前看”，而在于“现场有没有被完整保存下来”。
必须满足的三个硬性条件
缺一不可，否则看到的调用栈（bt）会截断、变量为空、甚至直接报 No stack.：
-
-g编译：用g++ -g -O0或至少-g2，避免优化导致内联/变量消除 -
ulimit -c unlimited：确保系统允许生成core文件；检查是否生效：ulimit -c输出应为unlimited -
core_pattern可达且有写权限：比如echo "/tmp/core.%p" | sudo tee /proc/sys/kernel/core_pattern，否则core可能被丢弃或写入不可见位置
启动 GDB 后第一件事：确认崩溃点和线程上下文
别急着 bt，先验证你拿到的是真实崩溃现场：
- 运行
gdb ./myapp /tmp/core.12345后，立即执行info signals，确认SIGSEGV或SIGABRT是否被标记为Stopped（而非Ignore） - 执行
thread apply all bt：多线程程序中，崩溃线程未必是主线程；SIGSEGV的栈顶通常就是非法访问点，但SIGABRT的栈顶只是“检测到错误”的位置，真正破坏可能发生在几十次 malloc/free 之前 - 用
frame 0切到最顶层帧，再list查看附近源码，确认该行是否真在操作指针或数组——有时符号错位是因为调试信息不匹配
想“追溯更早行为”？靠变量值和内存快照反推
GDB 不记录执行流日志，但崩溃时刻的内存是冻结的。你能做的只有从现场证据出发做合理推断：
- 对疑似野指针：用
p/x $rdi（x86_64）或p/x $r0（ARM）看寄存器里存的地址，再x/10xw 0xdeadbeef查看那片内存是否已释放或未初始化 - 对容器越界：若崩溃在
std::vector::at，用p _M_impl._M_finish和p _M_impl._M_start算出容量，再比对下标值 - 对堆损坏线索：运行
info proc mappings找 libc 基址，再call malloc_stats()（需 libc 调试符号）看是否有 fastbin corruption 提示
真正的“崩溃前路径”藏在变量生命周期和内存状态里，而不是指令序列里——这是最容易忽略的思维拐点。
