写 C++的同学想必有太多和内存打交道的血泪经验了，常常被 C++的内存问题搅的焦头烂额。（写 core 的经验了）有很多同学一见到 core 就两眼一抹黑，不知所措了。笔者 入"坑"C++之后，在调试 C++代码的过程之中，学习了不少调试代码内存的工具。希望借这个机会来介绍一下笔者常用的工具，GDB，Valgrind等等，相信大家通过好好运用这些工具，能更好的驯服内存这匹"野马"。

1.利用 GDB 调试 CoreDump

CoreDump时一个二进制的文件，进程发生错误崩溃时，内核会产生一个瞬时的快照，记录该进程的内存、运行堆栈状态等信息保存在core文件之中。做个简单的类比，core 文件相当于飞机运行时的"黑匣子"，能够帮助我们更好的调试 C++程序的问题。OK，接下来笔者将介绍一下如果利用GDB 来调试 CoreDump的文件。

• CoreDump 文件的大小

首先我们先确定一下操作系统是否会产生 CoreDump 文件。通过ulimit -c获取 core 文件的限制大小：

上面显示笔者电脑的 core 文件的大小是0，我们需要调整一下。通过ulimit调整为无限制。当然这种调整是临时的，reboot 之后就恢复为0了。

ulimit -c ulimited

如果需要永久修改，可以通过/etc/security/limits.conf 来修改 core 文件的大小。

• CoreDump 文件的生成路径
  默认情况下，core dump生成的文件名为core，而且就在程序当前目录下。通过修改/proc/sys/kernel/core_pattern可以控制core文件保存位置和文件格式。（建议将后缀改为进程号） 笔者这里简单起见，不进行修改了。

• 编写core 代码，这里笔者利用线程访问了空指针

#include <unistd.h> #include <thread>  void core() {     char* ch = nullptr;     *ch = 'a'; }  int main() {     auto t1 = std::thread(core);     sleep(5);     return 0; }

• 编译运行该代码，产生段错误，生成了 core 文件
  

• 利用 GDB 调试 core 文件
  调试 core 文件需要利用原生编译出的二进制文件调试。这里有一点需要注意的，如果编译 C++文件之时没有加-g的编译选项，core 文件的调试内容会不够完整。笔者这里建议开启对应的编译选项，这会导致对应的二进制文件变大，编译时间变长。（生产环境可以考虑关闭）使用gdb 二进制文件 core 文件打开 core 文件。

core 文件列出了两个线程的信息。我们需要判断对应的问题代码的定位，接下来我们一起来梳理一下：
用info thread查看线程的运行情况，在这里我们就可以判断代码 core 在什么线程之中了，如果还是无法确定，可以通过thread apply all bt列出更加详尽的堆栈信息。

通过上述信息可以确认，thread 1的代码存在问题。我们通过thread 1切换到 thread 1，用bt显示堆栈信息继续追查：

之后我们来看看令人生疑的栈内容，这里显然栈0是我们怀疑的代码，用frame 1查看。