C++程序崩潰現場破案指南：讓 core dump 乖乖交代真相！
作者：xiaokang1998
當下次你的程序崩潰時，不要驚慌，拿出你的"偵探工具箱"，沉著冷靜地說："給我一個core dump，我能告訴你哪里出了問題！"
大家好，我是小康。今天我們來聊一聊程序員噩夢中的常客——程序崩潰問題。作為一名C++開發者，我敢打賭你一定經歷過這樣的場景：
- 你是否曾在深夜里，對著終端屏幕上的"Segmentation fault (core dumped)"發呆?
- 你是否曾經為了一個神秘的崩潰問題，徹夜難眠，卻無從下手?
- 你是否曾經羨慕那些能迅速定位崩潰問題的大佬，覺得那是一種"神秘技能"?
如果你點頭了，那么恭喜你，今天這篇文章就是為你量身定做的！
一、什么是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可以避免這類問題。
這個例子展示了C++中最常見且最難調試的問題之一：懸空指針（dangling pointers）。在復雜系統中，對象的生命周期管理不當經常導致這類問題，而 core dump 分析是發現它們的有力工具。
八、常見崩潰類型及解決方法
通過core dump文件，我們可以診斷出很多常見的崩潰類型：
(1) 空指針解引用（剛才第一個例子）
- 癥狀：訪問地址0x0附近的內存
- 解決：使用前檢查指針是否為nullptr
(2) 數組越界
- 癥狀：訪問數組邊界之外的內存
- 解決：確保索引在有效范圍內，使用at()等帶邊界檢查的方法
(3) 使用已釋放的內存（懸空指針）
- 癥狀：訪問已經被free或delete的內存
- 解決：釋放后將指針置空，使用智能指針
(4) 棧溢出
- 癥狀：遞歸太深或局部變量太大
- 解決：控制遞歸深度，大數組使用堆內存
(5) 多線程數據競爭
- 癥狀：不確定位置崩潰，與時序有關
- 解決：正確使用鎖或其他同步機制
九、預防勝于治療：避免崩潰的最佳實踐
- 使用智能指針：std::unique_ptr和std::shared_ptr可以自動管理內存
std::unique_ptr<int[]> data = std::make_unique<int[]>(10);- 使用邊界檢查：優先使用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;
}- 啟用編譯器警告：
g++ -Wall -Wextra -Werror -g program.cpp -o program- 使用靜態分析工具：如cppcheck、Clang Static Analyzer
- 內存檢查工具：如Valgrind、AddressSanitizer
g++ -g -fsanitize=address program.cpp -o program十、總結：成為C++崩潰現場的"神探"
通過本文的學習，你現在應該掌握了：
- 如何設置系統生成 core dump 文件
- 如何使用 GDB 分析 core dump 找出崩潰原因
- 如何識別并解決常見的崩潰問題
- 如何預防程序崩潰
記住，調試程序崩潰就像偵探破案 - 需要仔細收集證據（core dump），分析線索（調用棧、變量值），最終找出"兇手"（bug）。
當下次你的程序崩潰時，不要驚慌，拿出你的"偵探工具箱"，沉著冷靜地說："給我一個core dump，我能告訴你哪里出了問題！"
彩蛋
如果你想測試自己是否真的掌握了這些知識，可以嘗試分析以下崩潰代碼并找出問題所在：
#include <iostream>
#include <string>
class Person {
private:
char* name;
int age;
public:
Person(conststd::string& n, int a) : age(a) {
name = newchar[n.length() + 1];
strcpy(name, n.c_str());
std::cout << "Person created: " << name << std::endl;
}
// 析構函數
~Person() {
std::cout << "Person destroyed: " << name << std::endl;
delete[] name;
}
// 拷貝構造函數 - 有重大缺陷！
Person(const Person& other) : age(other.age) {
// 淺拷貝！只復制了指針，沒有復制內容
name = other.name; // 危險！兩個對象指向同一塊內存
}
void introduce() {
std::cout << "Hi, I'm " << name << ", " << age << " years old." << std::endl;
}
};
int main() {
{
Person original("Alice", 30);
original.introduce();
// 創建一個副本
Person copy = original; // 使用有缺陷的拷貝構造函數
copy.introduce();
// 這里會發生什么？當original和copy都被銷毀時...
} // 作用域結束，兩個對象都會被銷毀
std::cout << "Program finished." << std::endl; // 這行會執行嗎？
return0;
}提示：這個程序會在哪里崩潰？為什么？如何修復它？
責任編輯：趙寧寧
來源：
跟著小康學編程
