gdb中run后瞬间退出通常因崩溃、正常结束或信号终止，需用info program查退出状态，backtrace定位栈帧，break _start/_libc_start_main捕获启动期错误，并确保编译带-g调试信息。
程序在 gdb 中 run 后瞬间退出、没报错也没停住，通常不是“没运行”，而是它跑完了、崩溃了、或被信号终止了——但你没看到关键线索。得让 gdb 把这些“一闪而过”的状态显性化。
确认是否真崩溃：先看 exit code 和 signal
运行后立刻退出，第一反应不是代码逻辑问题，而是程序是否异常终止。gdb 默认不会自动打印退出原因，必须主动查：
- 执行
run后，立刻输入info program—— 它会告诉你程序是exited normally还是exited with code X，或者更关键的：received signal SIGSEGV、SIGABRT等 - 如果看到
signal，说明崩溃了，但没触发断点或没生成 core；此时直接输backtrace（或bt）看栈帧，往往就能定位到最后一行 - 如果显示
exited normally但你预期它该卡住或等待输入，说明主函数已执行完毕（比如main里没getchar()或while(1)），属于逻辑提前结束，不是 bug
为什么没停在 main？检查是否跳过了入口
有些程序（尤其 Qt、GLib 或带初始化逻辑的 C++ 项目）在真正进入 main 前就崩溃了，比如全局对象构造失败、动态库加载失败、或 __libc_start_main 调用前出错。这时 run 看似“没反应”，其实是崩在比 main 更早的位置：
- 启动时加
-q参数抑制欢迎信息，减少干扰：gdb -q ./myapp - 用
break *0下一个“地址 0”断点（极少见），更实用的是：break _start或break __libc_start_main，然后run，看能不能停住 - 若停在
_start后立刻stepi（单条汇编指令），可观察是否卡在call某个初始化函数上——这时候info registers和x/10i $pc就很有用
程序秒退但没 signal？检查 stdout/stderr 是否被重定向或缓冲
看起来“什么都没输出就结束了”，有时只是输出被缓存或重定向走了，导致你以为它没运行到 printf 那行：
- 在源码中关键位置加
fflush(stdout)或用setvbuf(stdout, NULL, _IONBF, 0)关闭缓冲，再重新编译（别忘了-g） - 启动 gdb 时用
gdb --args ./myapp > out.log 2>&1捕获所有输出，再run，结束后检查out.log - 进 gdb 后用
set environment LD_DEBUG=libs（慎用，输出极多），可看动态库加载是否失败；失败时常见错误如cannot open shared object file，但默认不显示在终端
最常被忽略的一点：没编译带调试信息
如果可执行文件是 release 版（没加 -g），gdb 虽能运行，但 list 看不到源码、backtrace 可能只显示 ??、甚至某些崩溃点无法准确定位到行号——你会误以为“没崩”，其实是 gdb “看不见”：
- 用
file ./myapp进 gdb 后，立刻输info sources，如果返回空或只列几个系统头，基本确认没调试信息 - 重新编译务必加
-g -O0（关优化，避免行号错乱），CMake 项目加-DCMAKE_BUILD_TYPE=Debug - 验证是否生效：
readelf -S ./myapp | grep debug应该输出多个.debug_*段
真正难排查的，往往是崩溃发生在 main 之前，或崩溃后没生成 core、又没 signal 提示——这时候得靠 info program 和 backtrace 连用，再配合关闭输出缓冲和确认调试符号，三者缺一不可。
