发布于 由admin

C++ Core Dump (核心转储) 分析：GDB / LLDB 事后调试崩溃

哈喽，各位好！今天咱们来聊聊C++程序崩溃后，如何利用Core Dump（核心转储）进行事后诸葛亮式的调试。别害怕，这听起来很高大上，但实际上，只要你掌握了几个关键技巧，就能像福尔摩斯一样，从崩溃的现场还原真相。

一、什么是Core Dump？

想象一下，你的C++程序正欢快地运行着，突然，它像一个喝醉的程序员一样，一头栽倒在地，停止了工作。更糟糕的是，它什么都没留下，让你完全摸不着头脑。Core Dump就像是程序临死前留下的一份“遗书”，它记录了程序崩溃时的内存状态、寄存器信息、堆栈信息等等。

简单来说，Core Dump就是程序在崩溃瞬间，将内存中的数据完整地保存到一个文件中。这个文件包含了程序运行时的全部信息，可以帮助我们分析崩溃的原因。

二、Core Dump的生成与配置

在开始分析之前，我们首先要确保系统能够生成Core Dump文件。默认情况下，有些系统可能禁用了Core Dump的生成，我们需要手动开启它。

  • Linux系统:

    • 使用ulimit -c命令可以查看当前Core Dump文件的大小限制。如果显示为0，表示Core Dump被禁用。

    • 使用ulimit -c unlimited命令可以取消Core Dump文件大小的限制。

    • 默认情况下，Core Dump文件通常保存在程序的当前目录下，文件名为core。可以使用/proc/sys/kernel/core_pattern文件来配置Core Dump文件的保存路径和文件名格式。例如，echo "/tmp/core.%e.%p" > /proc/sys/kernel/core_pattern可以将Core Dump文件保存在/tmp目录下，文件名为core.<程序名>.<进程ID>。

    • 要永久生效，需要修改/etc/security/limits.conf文件，添加如下内容：

      * soft core unlimited
* hard core unlimited

    • 重启系统或者重新登录用户后生效。

  • macOS系统:

    • macOS默认情况下也会禁用Core Dump。

    • 使用launchctl limit core命令可以查看当前Core Dump文件的大小限制。

    • 要启用Core Dump，需要执行以下命令：

      sudo launchctl limit core unlimited

    • macOS会将Core Dump文件保存在/cores目录下，文件名为core.<进程ID>。

    • 要永久生效，需要修改/etc/launchd.conf文件，添加如下内容（如果文件不存在，则创建）：

      limit core unlimited

    • 重启系统后生效。

注意： 启用Core Dump可能会占用大量的磁盘空间，请根据实际情况进行配置。

三、使用GDB分析Core Dump

GDB（GNU Debugger）是Linux和类Unix系统下常用的调试器，它可以用来分析Core Dump文件。

  1. 加载Core Dump文件:

    gdb <程序名> <core文件>

    例如：

    gdb my_program core.12345

    这会将my_program程序和core.12345 Core Dump文件加载到GDB中。

  2. 常用GDB命令:

    • bt (backtrace): 显示函数调用栈，可以帮助我们找到崩溃发生的位置。
    • frame <帧号>: 切换到指定的函数帧。
    • info locals: 显示当前函数帧的局部变量。
    • print <变量名>: 打印变量的值。
    • list <行号>: 显示源代码。
    • quit: 退出GDB。

  3. 实例演示:

    假设我们有以下C++代码：

    #include <iostream>
#include <vector>

int main() {
    std::vector<int> my_vector;
    my_vector.reserve(10); // 预留空间
    my_vector[10] = 123; // 越界访问
    std::cout << "Hello, world!" << std::endl;
    return 0;
}

    这段代码存在越界访问的错误，当我们运行它时，会产生Core Dump。

    编译代码：

    g++ -g -o my_program main.cpp

    注意： -g选项是为了在生成的可执行文件中包含调试信息，这对于分析Core Dump至关重要。

    运行程序：

    ./my_program

    程序崩溃后，会生成一个名为core的Core Dump文件（或者根据你的配置，文件名可能有所不同）。

    使用GDB分析Core Dump：

    gdb my_program core

    在GDB中，输入bt命令，可以看到类似以下的输出：

    #0  __gnu_cxx::new_allocator<int>::construct (this=0x7fffffffe4b0, __p=0x60c014) at /usr/include/c++/9/ext/new_allocator.h:144
#1  std::allocator_traits<std::allocator<int> >::construct<int, int&> (__a=..., __p=0x60c014, __args#0=@0x7fffffffe4bc: 123) at /usr/include/c++/9/bits/alloc_traits.h:486
#2  std::vector<int, std::allocator<int> >::emplace_back<int&> (this=0x60b010, __args#0=@0x7fffffffe4bc: 123) at /usr/include/c++/9/bits/vector.tcc:109
#3  std::vector<int, std::allocator<int> >::operator[] (this=0x60b010, __n=10) at /usr/include/c++/9/bits/vector.tcc:501
#4  main () at main.cpp:7

    从输出中我们可以看到，崩溃发生在main.cpp的第7行，也就是my_vector[10] = 123;这一行。结合代码，我们很容易就能发现是越界访问导致的崩溃。

    我们还可以使用frame 4命令切换到main函数的帧，然后使用list命令查看源代码：

    (gdb) frame 4
#4  main () at main.cpp:7
7          my_vector[10] = 123; // 越界访问

    这样可以更加清晰地看到崩溃发生的位置。

    我们也可以查看变量的值，例如：

    (gdb) print my_vector
$1 = {
  _M_impl = {
    _M_start = 0x60b010,
    _M_finish = 0x60b010,
    _M_end_of_storage = 0x60b038
  }
}

    从输出中我们可以看到，my_vector的_M_start和_M_finish指针指向同一个地址，表示my_vector的大小为0。而_M_end_of_storage指向了预留空间的末尾。因此，访问my_vector[10]会导致越界访问。

四、使用LLDB分析Core Dump

LLDB（Low Level Debugger）是macOS和iOS系统下常用的调试器，它也可以用来分析Core Dump文件。LLDB与GDB在命令和使用方式上有很多相似之处，如果你熟悉GDB，那么学习LLDB会很容易。

  1. 加载Core Dump文件:

    lldb -c <core文件> <程序名>

    例如：

    lldb -c core.12345 my_program

    这会将core.12345 Core Dump文件和my_program程序加载到LLDB中。

  2. 常用LLDB命令:

    • bt (backtrace): 显示函数调用栈。
    • frame select <帧号>: 切换到指定的函数帧。
    • frame variable: 显示当前函数帧的局部变量。
    • print <变量名>: 打印变量的值。
    • list <行号>: 显示源代码。
    • quit: 退出LLDB。

  3. 实例演示:

    使用与GDB相同的C++代码，我们同样可以利用LLDB分析Core Dump。

    lldb -c core my_program

    在LLDB中，输入bt命令，可以看到类似以下的输出：

    * thread #1, stop reason = EXC_BAD_ACCESS (code=1, address=0x60000000c028)
    frame #0: 0x0000000100001160 my_program`std::vector<int, std::allocator<int> >::operator[](unsigned long) at vector:1095
    frame #1: 0x0000000100000f7b my_program`main at main.cpp:7
    frame #2: 0x0000000180a14f2f dyld`start + 2359

    从输出中我们可以看到，崩溃发生在main.cpp的第7行，也就是my_vector[10] = 123;这一行。

    我们还可以使用frame select 1命令切换到main函数的帧，然后使用list命令查看源代码：

    (lldb) frame select 1
frame #1: 0x0000000100000f7b my_program`main at main.cpp:7
   5    int main() {
   6        std::vector<int> my_vector;
-> 7        my_vector[10] = 123; // 越界访问
   8        std::cout << "Hello, world!" << std::endl;
   9        return 0;
   10   }

    这样可以更加清晰地看到崩溃发生的位置。

    我们也可以查看变量的值，例如：

    (lldb) print my_vector
(std::vector<int, std::allocator<int> >) my_vector = size=0 capacity=0 {
}

    从输出中我们可以看到，my_vector的大小为0，容量为0。因此，访问my_vector[10]会导致越界访问。

五、一些常见问题和技巧

  • 符号表丢失: 如果没有调试信息（例如，编译时没有使用-g选项），GDB/LLDB将无法显示源代码，只能显示汇编代码。因此，在编译程序时，一定要加上-g选项。
  • 优化的影响: 编译器优化可能会改变代码的执行顺序，使得调试更加困难。如果可能，在调试时可以禁用优化选项（例如，使用-O0选项）。
  • 多线程程序: 对于多线程程序，Core Dump文件会包含所有线程的信息。可以使用info threads命令查看所有线程，然后使用thread <线程ID>命令切换到指定的线程。
  • 远程调试: 可以使用GDB/LLDB进行远程调试，例如，调试运行在嵌入式设备上的程序。
  • 自定义Core Dump处理: 可以编写自定义的Core Dump处理程序，用于在程序崩溃时执行一些特定的操作，例如，发送崩溃报告到服务器。

六、总结

Core Dump分析是解决C++程序崩溃问题的重要手段。通过GDB/LLDB等调试器，我们可以从Core Dump文件中提取有用的信息，例如函数调用栈、变量值等，从而找到崩溃的原因。掌握Core Dump分析技巧，可以帮助我们更快地定位和解决问题，提高开发效率。

希望今天的讲解对你有所帮助。记住，遇到崩溃不要慌，Core Dump在手，天下我有！ 祝大家编程愉快！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注