GDB通过捕获SIGSEGV等信号及设置条件断点可在崩溃前暂停程序；若信号被程序自定义处理或环境屏蔽，则需显式配置handle命令或调整运行环境。
崩溃前停住的关键：信号捕获与断点设置
GDB 不能“预知”崩溃，但能拦截导致崩溃的信号（如 SIGSEGV、SIGABRT），在系统真正终止程序前接管控制权。这相当于在病人倒下瞬间按住他，而不是等他躺平了再检查——前提是 GDB 已在运行且信号未被程序忽略或处理。
-
SIGSEGV（段错误）、SIGABRT（abort）、SIGFPE（浮点异常）默认会被 GDB 捕获并暂停，无需额外配置 - 如果程序自己
signal(SIGSEGV, handler)或用sigaction拦截了这些信号，GDB 就收不到——此时需在启动 GDB 后执行：handle SIGSEGV stop print强制接管 - 对
SIGPIPE、SIGHUP等默认忽略的信号，GDB 默认不中断；要用handle SIGPIPE stop print显式启用
用条件断点模拟“崩溃前一刻”
很多崩溃源于特定数据状态（比如指针为 NULL、数组索引越界、除零），与其等它炸，不如在可疑逻辑入口设条件断点，提前介入。
- 在可能解引用空指针的位置前设断点：
break file.c:42 if ptr == 0 - 在循环内监控越界风险：
break loop.c:88 if i >= array_size - 避免重复触发：用
tbreak（只生效一次）或ignore 1 999跳过前 N 次 - 注意：条件表达式里不能调用可能改变程序状态的函数（如
printf），GDB 会拒绝执行
core 文件生成后，GDB 还能“回到崩溃前”吗？
不能。core 文件是崩溃**瞬间**的内存快照，寄存器、栈帧、堆状态都已冻结。你看到的 bt 是崩溃发生时的调用栈，不是“上一步”——GDB 无法从 core 中还原出崩溃前的变量变化过程。
- 想追溯变化，必须在运行时调试：编译加
-g -O0，用watch监视关键变量（如watch *(int*)0xdeadbeef），或用display自动打印表达式值 - core 文件唯一能做的，是确认崩溃点在哪一行、哪个线程、寄存器值为何（
info registers）、是否跳转到了非法地址（x/10i $rip） - 若崩溃发生在第三方库或优化代码中，
-O0和-g缺一不可，否则bt可能显示??或错行
容易被忽略的陷阱：SIGSEGV 被吞掉或延迟
有些场景下，你明明设置了 handle SIGSEGV stop，GDB 却没停住——不是 GDB 失效，而是信号被别的机制截断了。
- 容器环境（Docker/Podman）默认禁用 core dump，且可能通过
prctl(PR_SET_DUMPABLE, 0)主动屏蔽信号传递，需启动时加--cap-add=SYS_PTRACE - 使用
pthread_sigmask屏蔽了SIGSEGV的线程，GDB 无法向其投递信号 - 程序用
setjmp/longjmp实现了自定义异常恢复，崩溃后直接跳走，GDB 来不及响应 - 多线程程序中，
SIGSEGV只发给触发线程，但 GDB 默认只关注主线程；要用thread apply all bt检查所有线程状态
真正可靠的“崩溃前停住”，永远依赖运行时干预：信号接管 + 条件断点 + 内存监视。指望 core 文件回溯逻辑流，就像拿着尸体做笔录——能知道死因，但问不出作案动机。
