C++程序崩溃转储（Core Dump）分析：利用GDB/LLDB进行事后调试
大家好！今天我们来深入探讨C++程序崩溃转储（Core Dump）分析，以及如何利用GDB/LLDB进行事后调试。程序崩溃是每个开发者都会遇到的问题，而Core Dump则是定位和解决这些问题的关键信息来源。
1. 什么是Core Dump？
Core Dump，也称为核心转储，是操作系统在程序异常终止时，将程序当时的内存状态（包括代码、数据、堆栈、寄存器等）保存到磁盘上的一个文件。这个文件就像程序的“遗照”，可以帮助我们了解程序崩溃时的具体情况。
更具体地说，Core Dump包含了以下重要信息：
- 程序代码段（Text Segment）： 程序的指令代码。
- 程序数据段（Data Segment）： 程序的全局变量、静态变量等。
- 堆（Heap）： 程序动态分配的内存。
- 栈（Stack）： 函数调用、局部变量等。
- 寄存器状态： CPU寄存器的值，例如程序计数器（PC）、栈指针（SP）等。
- 进程信息： 进程ID、用户ID等。
- 信号信息： 导致程序崩溃的信号。
2. 为什么需要Core Dump？
Core Dump的作用在于：
- 事后调试： 在程序崩溃后，我们可以使用调试器（GDB/LLDB）加载Core Dump文件，并像调试运行中的程序一样，查看内存、堆栈、变量等信息，从而定位崩溃原因。
- 离线分析： 即使程序在生产环境中崩溃，我们也可以将Core Dump文件复制到开发环境中进行分析，而无需在生产环境中重现崩溃。
- 历史记录： Core Dump可以作为程序崩溃的历史记录，方便我们追踪和解决问题。
3. 如何生成Core Dump？
在Linux系统中，默认情况下，Core Dump功能可能是关闭的。我们需要手动启用它。
-
检查Core Dump是否开启:
使用
ulimit -c命令查看当前的core file size limit。如果输出为0，则表示Core Dump功能已关闭。 -
开启Core Dump:
使用
ulimit -c unlimited命令开启Core Dump功能。这将允许生成任意大小的Core Dump文件。也可以设置一个具体的大小，例如ulimit -c 1024(单位为KB)。 -
设置Core Dump文件的存储路径和命名规则：
可以通过修改
/proc/sys/kernel/core_pattern文件来设置Core Dump文件的存储路径和命名规则。例如：sudo echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern这条命令将Core Dump文件存储到
/tmp目录下，文件名为core.<程序名>.<进程ID>。也可以使用
sysctl命令进行永久设置，修改/etc/sysctl.conf文件，添加或修改以下行：kernel.core_pattern = /tmp/core.%e.%p fs.suid_dumpable = 2并执行
sudo sysctl -p使配置生效。fs.suid_dumpable = 2允许 setuid 程序产生 core dump。 -
代码触发Core Dump（仅用于测试）：
在程序中故意制造一个错误，例如空指针解引用，来触发Core Dump。
#include <iostream> int main() { int* ptr = nullptr; *ptr = 10; // 空指针解引用，触发崩溃 std::cout << "This line will not be printed." << std::endl; return 0; }编译并运行该程序，程序会崩溃，并在指定目录下生成Core Dump文件。
4. 使用GDB/LLDB分析Core Dump
假设我们已经生成了一个名为 core.example.1234 的Core Dump文件，其中 example 是程序名，1234 是进程ID。
-
使用GDB:
gdb example core.example.1234 -
使用LLDB:
lldb example -c core.example.1234启动调试器后，我们可以使用以下命令进行分析：
bt(backtrace)：查看函数调用堆栈。这是定位崩溃点的关键。frame <number>：选择堆栈中的某一帧。info locals：查看当前帧的局部变量。info args：查看当前帧的函数参数。print <variable>：打印变量的值。list：显示源代码。disassemble：反汇编代码。x/<format> <address>：查看内存地址的内容。例如，x/10wx 0x400000查看从地址0x400000开始的10个字（word）。
5. 调试技巧和常见问题
-
符号文件： 调试器需要符号文件才能将内存地址映射到源代码行号和函数名。确保在编译程序时包含了调试信息（
-g选项）。如果Core Dump是在没有调试信息的程序上生成的，调试器将只能显示内存地址和汇编代码，这会大大增加调试难度。 -
优化代码： 优化后的代码可能会使调试更加困难，因为编译器可能会删除或重排变量和函数。建议在调试时关闭优化选项（
-O0）。 -
动态链接库： 如果程序使用了动态链接库，Core Dump文件可能不包含动态链接库的信息。需要在调试器中手动加载动态链接库。
-
多线程程序： 如果程序是多线程的，可以使用
thread apply all bt命令查看所有线程的堆栈信息。 -
内存损坏： 内存损坏是C++程序崩溃的常见原因。可以使用内存调试工具（例如Valgrind）来检测内存泄漏、越界访问等问题。
-
信号处理： 程序崩溃时，操作系统会向程序发送一个信号。可以使用
info signals命令查看程序接收到的信号。
6. 实战案例：分析一个简单的崩溃
假设我们有以下程序：
#include <iostream>
#include <vector>
int main() {
std::vector<int> numbers;
numbers.push_back(1);
numbers.push_back(2);
numbers.push_back(3);
// 访问越界
std::cout << numbers[5] << std::endl;
return 0;
}编译并运行该程序，程序会因为访问越界而崩溃。生成Core Dump文件后，我们使用GDB进行分析：
gdb example core.example.1234在GDB中，我们输入 bt 命令查看堆栈信息：
#0 __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#1 0x00007ffff7b047f3 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#2 0x00007ffff7b04868 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#3 0x00007ffff7b04a7e in __cxa_throw (obj=0x602000000010, tinfo=0x7ffff7d77f60 <typeinfo for std::out_of_range>, dest=0x7ffff7b0a5e0 <std::out_of_range::~out_of_range()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:94
#4 0x00007ffff7b4550f in std::__throw_out_of_range_fmt(char const*, ...) () at ../../../../libstdc++-v3/src/c++11/functexcept.cc:65
#5 0x00007ffff7b47c8a in std::vector<int, std::allocator<int> >::operator[](unsigned long) () at /usr/include/c++/5/bits/stl_vector.h:808
#6 0x000000000040073d in main () at example.cpp:10从堆栈信息中，我们可以看到程序在 std::vector<int, std::allocator<int> >::operator[] 函数中抛出了 std::out_of_range 异常，这是因为我们访问了 numbers[5]，而 numbers 的大小只有3。
我们还可以使用 list 命令查看 example.cpp:10 的源代码：
5 #include <vector>
6
7 int main() {
8 std::vector<int> numbers;
9 numbers.push_back(1);
10 numbers.push_back(2);
11 numbers.push_back(3);
12
13 // 访问越界
14 std::cout << numbers[5] << std::endl;
15
16 return 0;这证实了我们的猜测。
7. Core Dump配置相关的表格信息
| 配置项 | 描述 | 默认值 | 示例 |
|---|---|---|---|
ulimit -c |
设置 core file size limit，控制 core dump 文件的大小。 | 0 (关闭) | ulimit -c unlimited 或 ulimit -c 1024 |
/proc/sys/kernel/core_pattern |
设置 core dump 文件的存储路径和命名规则。 %e: 程序名, %p: 进程ID, %s: 导致dump的信号, %t: dump发生的时间, %h: 主机名。 |
core (当前目录) |
/tmp/core.%e.%p |
fs.suid_dumpable |
控制 setuid/setgid 程序是否可以生成 core dump。 | 0 (不允许) | 2 (允许) |
8. 使用LLDB进行Core Dump分析的命令示例
| 命令 | 描述 | 示例 |
|---|---|---|
bt |
显示当前线程的堆栈回溯。 | bt |
thread list |
列出所有线程。 | thread list |
thread select <id> |
选择要调试的线程。 | thread select 2 |
frame info |
显示当前帧的信息，包括函数名、源文件和行号。 | frame info |
frame variable |
显示当前帧的局部变量。 | frame variable |
expression <expr> |
计算表达式的值。 | expression a + b |
memory read <addr> |
读取指定内存地址的内容。 | memory read 0x12345678 |
disassemble |
反汇编当前函数。 | disassemble |
image lookup --address <addr> |
查找指定地址对应的符号信息。 | image lookup --address 0x400000 |
breakpoint set --file <file> --line <line> |
在指定的源文件和行号处设置断点。 在加载core dump后，断点依然有效，可以方便地查看特定代码位置的状态。 | breakpoint set --file main.cpp --line 15 |
9. 解决 No symbol table is loaded. Use the "file" command. 错误
在使用GDB/LLDB分析Core Dump时，你可能会遇到 "No symbol table is loaded. Use the "file" command." 错误。 这通常意味着调试器无法找到与Core Dump对应的程序的可执行文件以及调试符号。 解决这个问题的方法有几个：
- 确保可执行文件存在： 调试器需要知道崩溃的程序的可执行文件。 在启动GDB/LLDB时，你必须提供这个可执行文件的路径。
- 确保调试符号存在： 调试符号将内存地址映射到源代码中的函数和变量。 编译程序时，请务必使用
-g选项来包含调试信息。 如果你没有调试符号，调试器将只能显示内存地址和汇编代码，这将使调试变得非常困难。 - 提供正确的路径： 如果可执行文件或调试符号不在默认路径中，你需要使用
file命令显式地告诉调试器它们的路径。 例如，在GDB中，你可以使用file /path/to/executable命令来加载可执行文件。 - 动态链接库： 如果程序使用了动态链接库，调试器可能无法自动加载这些库的符号。 你可以使用
sharedlibrary命令来手动加载共享库。 例如，在GDB中，你可以使用sharedlibrary libmylibrary.so命令来加载libmylibrary.so库。 - Core Dump文件不完整： 某些情况下，Core Dump文件可能因为各种原因不包含完整的符号信息。 这种情况下，你可能需要重新生成Core Dump文件，并确保在生成Core Dump时，所有必要的符号都可用。
10. 常见的崩溃原因及其分析方法
| 崩溃原因 | 分析方法 |
|---|---|
| 空指针解引用 | 查看崩溃时的堆栈信息，找到解引用空指针的代码位置。检查指针是否被正确初始化，或者在使用前是否进行了有效性检查。 |
| 数组越界访问 | 查看崩溃时的堆栈信息，找到数组访问的代码位置。检查数组索引是否超出了数组的边界。 |
| 堆栈溢出 | 堆栈溢出通常是由递归调用过深或局部变量过大引起的。查看堆栈信息，找到递归调用的代码位置，或者检查局部变量的大小。 |
| 内存泄漏 | 内存泄漏会导致程序耗尽所有可用内存，最终导致崩溃。使用内存调试工具（例如Valgrind）来检测内存泄漏。 |
| 线程同步问题 | 在多线程程序中，线程同步问题（例如死锁、竞争条件）会导致程序崩溃。使用线程调试工具来检测线程同步问题。 |
| 除零错误 | 查看崩溃时的堆栈信息，找到除法运算的代码位置。检查除数是否为零。 |
| double free/corruption | 使用 valgrind 等工具检查内存是否被重复释放，或者是否存在内存损坏的情况。 堆损坏可能导致后续的内存操作出现问题。 |
总结：利用Core Dump进行高效调试
Core Dump是定位C++程序崩溃的有力武器。通过合理配置Core Dump生成，并结合GDB/LLDB等调试工具，我们可以快速定位崩溃原因，提高调试效率。 掌握Core Dump分析技术，是每个C++开发者必备的技能。 记住，仔细分析堆栈信息、变量值，并结合源代码，才能找到问题的根源。
更多IT精英技术系列讲座，到智猿学院