GDB无法直接附加已崩溃进程，只能分析core文件；需提前启用core dump、编译时加-g选项，并用gdb ./myapp ./core回溯调用栈定位问题。
直接用 GDB 附加到崩溃进程本身是行不通的——进程一旦崩溃（比如触发 SIGSEGV），就已终止，只剩下一个 core 文件。真正能做的，是用 GDB 分析这个 core 文件，结合原始可执行程序，还原崩溃瞬间的状态。整个过程不依赖进程是否还在运行，而是靠“事后解剖”来定位问题。
确保能拿到 core 文件
很多系统默认禁用 core dump，必须提前配置，否则崩溃后什么也留不下：
- 临时启用：
ulimit -c unlimited（当前终端生效） - 永久生效：在
/etc/security/limits.conf中添加两行* soft core unlimited<br>* hard core unlimited
- 指定 core 存储位置和命名（推荐）：
echo '/var/core/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
然后创建目录：sudo mkdir -p /var/core && sudo chmod 777 /var/core
编译时必须带调试信息
GDB 要把内存地址映射回源码，离不开 -g 编译选项。没有它，bt 只能看到地址，看不到函数名和行号：
- C 程序：
gcc -g -O0 -o myapp myapp.c - C++ 程序：
g++ -g -O0 -o myapp myapp.cpp -
-O0关闭优化，避免变量被删、代码重排，让调试结果更可信
用 GDB 加载 core 进行分析
崩溃发生后，找到对应的 core 文件和原始可执行文件，启动分析：
- 命令格式：
gdb ./myapp ./core.xxx（路径要写全） - 进 GDB 后第一件事：
bt（或backtrace）——看调用栈，定位最顶层的崩溃点 - 如果栈里有多个线程，用
info threads查看所有线程，再用thread apply all bt看全部栈帧 - 切换到关键栈帧：
frame 2（数字来自bt输出），再用list查看附近源码，print 变量名检查值
没生成 core？补救方法
如果现场没开 core dump，但程序还能复现崩溃，可以手动触发并捕获：
- 用
gdb ./myapp启动程序（不加 core） - 运行：
run，等它崩溃 - GDB 会自动停在崩溃点，此时直接输入
bt和info registers，效果等同于分析 core - 也可在崩溃暂停时，用
generate-core-file命令手动生成一个 core 文件供后续复用
