c++：C++程序崩溃现场破案指南：让 core dump 乖乖交代真相！（转载）
地址：「程序员救星」C++程序崩溃现场破案指南：让 core dump 乖乖交代真相！
什么是core dump？别被这个名字吓到
先别被"core dump"这个听起来很高大上的名字吓到。简单来说，core dump就是程序崩溃时的"现场照片"。
想象一下，你的程序就像一个在高速公路上奔驰的赛车。突然，"砰"的一声，它撞墙了（崩溃了）。此时操作系统会立即拍下事故现场的全景照片，把车子的状态、路况、方向盘位置等信息都记录下来 - 这就是core dump文件。
它包含了程序崩溃那一刻的所有内存信息、寄存器状态、调用栈等关键数据，是我们破案的重要线索！
让core dump现身：设置环境才能留下"罪证"
在很多Linux系统中，core dump功能默认是关闭的。所以我们首先要让系统在程序崩溃时乖乖交出"现场照片"。
# 查看当前core dump设置
ulimit -c
# 如果显示0，说明core dump功能被禁用了
# 开启core dump功能（不限制大小）
ulimit -c unlimited
# 设置core文件的存放位置和命名方式（以Ubuntu为例）
sudo sh -c 'echo "kernel.core_pattern=/tmp/core-%e-%p-%t" > /etc/sysctl.d/50-coredump.conf'
sudo sysctl -p /etc/sysctl.d/50-coredump.conf这样设置后，当程序崩溃时，系统会在 /tmp 目录下生成一个 core 文件，文件名包含程序名(-e)、进程ID(-p)和时间戳(-t)。
制造一个崩溃现场：来个"真实案例"
为了让大家有直观感受，我们先制造一个典型的C++程序崩溃：
// crash.cpp - 一个会崩溃的小程序
#include <iostream>
void dangerous_function() {
int* ptr = nullptr; // 空指针
*ptr = 42; // 灾难即将发生！
}
void another_function() {
dangerous_function();
}
int main() {
std::cout << "准备崩溃，请系好安全带..." << std::endl;
another_function();
std::cout << "这行永远不会执行到..." << std::endl;
return0;
}编译并运行它：
g++ -g crash.cpp -o crash # -g选项很重要！它会加入调试信息
./crash"砰！"程序崩溃了，终端显示：
准备崩溃，请系好安全带...
Segmentation fault (core dumped)现在去/tmp目录看看，应该能找到一个名为core-crash-进程ID-时间戳的文件。这就是我们的"现场照片"！
侦探工作开始：解读core dump文件
有了core dump文件，我们就可以开始破案了。我们需要一个强大的工具——GDB（GNU调试器）。
gdb ./crash /tmp/core-crash-xxxx-xxxx一进入GDB，它就会告诉你程序是在哪里崩溃的：
Core was generated by `./crash'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000555555555175 in dangerous_function() at crash.cpp:5
5 *ptr = 42; // 灾难即将发生！看！它直接指出了问题所在：crash.cpp文件的第 5 行，我们试图往空指针写入数据。
深入调查：查看完整调用栈
但这只是冰山一角。在实际项目中，我们需要了解更多信息，比如程序是从哪里调用到崩溃点的。使用bt命令可以查看完整调用栈：
(gdb) bt
#0 0x0000555555555175 in dangerous_function() at crash.cpp:5
#1 0x00005555555551a3 in another_function() at crash.cpp:9
#2 0x00005555555551bf in main() at crash.cpp:14这个调用栈清楚地展示了程序的执行路径：main函数调用了another_function，而another_function 又调用了 dangerous_function，最终在 dangerous_function 中崩溃。
收集更多证据：查看变量值
我们可以进一步检查崩溃时各个变量的值：
(gdb) frame 0
#0 0x0000555555555175 in dangerous_function() at crash.cpp:5
5 *ptr = 42; // 灾难即将发生！
(gdb) print ptr
$1 = (int *) 0x0这证实了 ptr 确实是一个空指针(0x0)。
我们还可以检查其他栈帧中的变量：
(gdb) frame 2
#2 0x00005555555551bf in main() at crash.cpp:14
14 another_function();
(gdb) list
9 void another_function() {
10 dangerous_function();
11 }
12
13 int main() {
14 std::cout << "准备崩溃，请系好安全带..." << std::endl;
15 another_function();
16 std::cout << "这行永远不会执行到..." << std::endl;
17 return 0;
18 }这样我们就获得了更多代码上下文信息。
实战：更复杂的案例分析
让我们看一个在实际开发中非常典型且常见的案例：释放后使用（Use After Free） 错误。这类问题特别容易产生core dump，且常常让开发者头疼不已。
// uaf_crash.cpp
#include <iostream>
#include <string>
#include <vector>
class User {
private:
std::string name;
int* score; // 动态分配的积分
public:
User(conststd::string& username, int initial_score) : name(username) {
score = newint(initial_score);
std::cout << "创建用户: " << name << ", 初始积分: " << *score << std::endl;
}
~User() {
std::cout << "销毁用户: " << name << std::endl;
delete score; // 释放内存
score = nullptr; // 这是个好习惯，但在析构函数中其实没有实际作用
}
void add_points(int points) {
*score += points;
std::cout << name << " 获得 " << points << " 积分，当前总分: " << *score << std::endl;
}
std::string get_name() const {
return name;
}
int get_score() const {
return *score; // 直接解引用，但如果score已经被释放，这里会崩溃
}
};
// 这个函数保存了对已删除对象的引用！
void process_later(const std::vector<User*>& users) {
// 假设这是一个延迟处理函数，在主程序的其他部分执行后才会运行
std::cout << "\n进行延迟处理..." << std::endl;
for (constauto& user : users) {
std::cout << "处理用户: " << user->get_name();
std::cout << ", 积分: " << user->get_score() << std::endl;
}
}
int main() {
std::vector<User*> active_users;
std::vector<User*> users_for_processing;
// 创建一些用户
User* alice = new User("Alice", 100);
User* bob = new User("Bob", 150);
User* charlie = new User("Charlie", 200);
active_users.push_back(alice);
active_users.push_back(bob);
active_users.push_back(charlie);
// 为一些用户增加积分
alice->add_points(50);
charlie->add_points(25);
// 将用户加入到待处理队列
users_for_processing.push_back(alice);
users_for_processing.push_back(bob);
std::cout << "\n删除一些用户..." << std::endl;
// 模拟用户注销，删除Bob
for (auto it = active_users.begin(); it != active_users.end(); ) {
if ((*it)->get_name() == "Bob") {
delete *it; // 释放Bob的内存
it = active_users.erase(it); // 从活跃用户列表移除
} else {
++it;
}
}
// 这里的问题是：Bob已经被删除，但users_for_processing中仍然保留了指向Bob的指针
// 当调用process_later时，尝试访问Bob的成员将导致崩溃
process_later(users_for_processing); // 这里会崩溃！
// 清理剩余用户
for (auto user : active_users) {
delete user;
}
return0;
}编译并运行这个程序：
g++ -g uaf_crash.cpp -o uaf_crash
./uaf_crash程序会输出：
创建用户: Alice, 初始积分: 100
创建用户: Bob, 初始积分: 150
创建用户: Charlie, 初始积分: 200
Alice 获得 50 积分，当前总分: 150
Charlie 获得 25 积分，当前总分: 225
删除一些用户...
销毁用户: Bob
进行延迟处理...
处理用户: Alice, 积分: 150
Segmentation fault (core dumped)完美！我们得到了一个core dump。现在用 GDB 分析：
gdb ./uaf_crash /tmp/core-uaf_crash-xxxx-xxxxGDB会告诉我们崩溃的位置：
warning: Section `.reg-xstate/3522' in core file too small.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
查看更多信息：
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fdc31ebb859 in __GI_abort () at abort.c:79
#2 0x00007fdc32154ee6 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007fdc32166f8c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007fdc32166ff7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007fdc32167258 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fdc321549ba in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007fdc3220c73a in void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x0000562f0f6f6d39 in User::get_name[abi:cxx11]() const (this=0x562f3f227710) at test2.cpp:29
#9 0x0000562f0f6f64d0 in process_later (users=std::vector of length 2, capacity 2 = {...}) at test2.cpp:43
#10 0x0000562f0f6f68c9 in main () at test2.cpp:83
(gdb) frame 8
#8 0x0000562f0f6f6d39 in User::get_name[abi:cxx11]() const (this=0x562f3f227710) at test2.cpp:29
29 return name;
(gdb) p *this
$1 = {name = <error reading variable: Cannot create a lazy string with address 0x0, and a non-zero length.>, score = 0x0}看到问题了吗？我们发现：程序在User::get_name()方法中崩溃，尝试访问空指针
通过调用栈，我们可以看到崩溃发生在process_later函数中，最终追溯到process_later 函数的第43行。
这是一个典型的Use After Free（释放后使用）错误：我们在第 74 行删除了 Bob 对象，但在第43行的process_later函数中仍然尝试使用指向已删除对象的指针。
如何修复这类问题？
使用智能指针：使用std::shared_ptr可以避免这类问题
std::vector<std::shared_ptr<User>> active_users;
std::vector<std::shared_ptr<User>> users_for_processing;
auto alice = std::make_shared<User>("Alice", 100);常见崩溃类型及解决方法
通过core dump文件，我们可以诊断出很多常见的崩溃类型：
1、 空指针解引用（刚才第一个例子）
-
症状：访问地址0x0附近的内存
-
解决：使用前检查指针是否为nullptr
2、 数组越界
-
症状：访问数组边界之外的内存
-
解决：确保索引在有效范围内，使用at()等带边界检查的方法
3、 使用已释放的内存（悬空指针）
-
症状：访问已经被free或delete的内存
-
解决：释放后将指针置空，使用智能指针
4、 栈溢出
-
症状：递归太深或局部变量太大
-
解决：控制递归深度，大数组使用堆内存
5、 多线程数据竞争
-
症状：不确定位置崩溃，与时序有关
-
解决：正确使用锁或其他同步机制
预防胜于治疗：避免崩溃的最佳实践
1、 使用智能指针：std::unique_ptr和std::shared_ptr可以自动管理内存
std::unique_ptr<int[]> data = std::make_unique<int[]>(10);2、 使用边界检查：优先使用STL容器，使用at()而非[]
std::vector<int> vec = {1, 2, 3};
try {
// 会抛出异常而非崩溃
vec.at(5) = 10;
} catch (const std::out_of_range& e) {
std::cerr << "捕获到异常: " << e.what() << std::endl;
}3、 启用编译器警告：
g++ -Wall -Wextra -Werror -g program.cpp -o program4、 使用静态分析工具：如cppcheck、Clang Static Analyzer
5、 内存检查工具：如Valgrind、AddressSanitizer
g++ -g -fsanitize=address program.cpp -o program总结：成为C++崩溃现场的"神探"
通过本文的学习，你现在应该掌握了：
-
如何设置系统生成 core dump 文件
-
如何使用 GDB 分析 core dump 找出崩溃原因
-
如何识别并解决常见的崩溃问题
-
如何预防程序崩溃
记住，调试程序崩溃就像侦探破案 - 需要仔细收集证据（core dump），分析线索（调用栈、变量值），最终找出"凶手"（bug）。
当下次你的程序崩溃时，不要惊慌，拿出你的"侦探工具箱"，沉着冷静地说："给我一个core dump，我能告诉你哪里出了问题！"
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)