C/C++ 程序崩溃不再难：VS Code 下从日志到 Core Dump 的排查策略

程序崩了不报行号，这是 VS Code 日常开发里最磨人的场景之一。尤其是 C/C++ 这类编译型项目，写完代码一运行，直接弹个“程序已停止工作”，终端里除了退出码，什么线索都没有。更头疼的是，这种崩溃往往不是必现的——可能调试的时候好好的，客户那边一跑就崩，或者运行半小时才崩一次。

我在实际开发里被这类问题折腾过很多次，从最开始在代码里疯狂加 printf 一行一行排查，到后来用调试器、转储文件、静态分析工具组合定位，踩的坑多了，慢慢总结出一套相对固定的排查思路。这篇文章就把我常用的方法完整梳理一遍，从最简单的日志定位，到 VS Code 里配置调试器的断点排查，再到 Core Dump 分析、编译器 sanitizer 的深度用法，希望能帮你少走点弯路。

1. 先搞清楚程序崩溃的几种典型形态

定位崩溃位置之前，得先明白崩溃本身也分类型。不同的崩溃形态，对应的排查手段完全不同。我在 VS Code 里折腾过几类，先给读者做个大概的分类。

1.1 解释型语言的异常崩溃

Python、JavaScript、Ruby 这类解释型语言，崩溃通常表现为异常抛出。这类异常的好处是大多自带堆栈信息，能直接告诉你崩在第几行。比如 Python 的 Traceback、Node.js 的 Error stack，基本上有手就行，不怎么需要额外工具。

但解释型语言也有难搞的时候。比如 Python 里用 C 扩展库（numpy、pandas 底层都有 C 代码）时，如果传入非法指针或内存越界，可能直接 Segfault，连 Traceback 都不给。Node.js 里跑原生模块（.node 文件）同理。这时候就得按编译型语言的方式处理了。

1.2 编译型语言的直接崩溃

C、C++、Rust（默认 release 模式）这类编译型语言，崩溃是赤裸裸的。最典型的就是段错误（Segmentation Fault），常见的成因不外乎空指针解引用、数组越界、释放后使用（use-after-free）、栈溢出。

这类崩溃最坑的地方在于：VS Code 的集成终端里通常只给你一句 Segmentation fault (core dumped)，行号、函数调用链一概没有。如果项目里没开调试信息编译选项，连用调试器附加上去都没法看到完整的符号信息。

1.3 资源型崩溃与系统强杀

还有一种类型容易被忽略——不是代码逻辑导致的崩溃，而是资源耗尽被系统杀掉。比如内存申请过大触发 OOM Kill，或者线程栈空间设置过小导致栈溢出，甚至 Windows 上访问了被保护的内存地址触发访问冲突。

这类“崩溃”往往不产生常规的异常对象，而是通过信号或退出码体现。Linux 上退出码 139 是段错误（128 + 11），134 是 SIGABRT（128 + 6）。Windows 上如果出现 0xc0000005 这种十六进制错误码，基本就是访问冲突。记住这些线索，能帮你快速缩小排查范围。

2. 从最朴素的 printf 定位到 Logger 分级输出

面对崩溃，很多人第一反应是“加打印看看”，这没什么丢人的。打印定位是最简单、最直接的手段，但具体怎么打印、打印什么，也是有讲究的。无脑往代码里插 printf 不是不行，但效率太低。

2.1 二分法插入临时输出

假设一块代码在运行到某个时刻崩了，但你不知道具体崩在哪一步，最笨也是最有效的办法是在代码块的起始、中间位置分别加输出，看哪行之前的打印执行了、哪行之后的没执行，就能把崩溃点位缩小到两大块之间。反复执行这个二分过程，几轮就能定位到具体的函数和语句。

但注意，这种定位法有个天然缺陷：加了输出之后，程序的执行时序会改变，对于多线程程序甚至可能影响崩溃是否触发。我遇到过加了一堆打印之后程序反而不崩了的情况，去掉打印立刻复现，让人哭笑不得。所以通过打印定位到的位置只能算“高度怀疑对象”，不能直接下结论。

2.2 VS Code 里配置输出面板和日志文件

如果项目规模不大，直接在代码里加临时输出还行。但项目一大，几十个文件，不可能每个函数都去插打印。更规范的做法是引入 Logger 分级日志，把不同级别的运行信息输出到文件或 VS Code 的“输出”面板里。

• debug 级别：记录进入某个关键函数、关键分支的判断结果，这类信息平时不需要全量打开，只在定位问题时临时调高日志级别。
• info 级别：记录程序启动参数、核心配置加载结果、主要流程里程碑。
• error 级别：记录可能出问题的分支——比如某个指针为 null、某个索引越界、某个文件打开失败。

日志输出的目标，建议优先写到文件而不是终端。因为终端缓冲区有限，崩溃前的大量输出会被截断或覆盖。写文件时尽量用追加模式，并且每条日志带上毫秒级时间戳，这样后续还能对照日志分析崩溃前的执行顺序。

2.3 打印要打在“可能有错”的前后而不是“可能出错”的那行

这里有个小经验，加打印不要只加在执行语句之间，要在可能出错的那条语句执行前后都加。比如：

cpp复制char* p = getBuffer(); // 假设这个函数可能返回 null
// 在 p 使用前打印它的值
fprintf(