记一次core 文件调试

无论是linux系统，还是windows系统，我们都有可能因为各种原因导致程序崩溃，那么这种情况下如何确认崩溃在哪了呢？

windows系统

这里是采用windows的api来产生dump文件

产生minidump的方法，网上都有，可以搜一下。

#include "DumpManager.h"

void main()
{
    DumpManager dump_manager(true);
    char* p = NULL;
    memcpy(p, "Hello", strlen("Hello"));
}

注：这里的DumpManager.h是崩溃后生成dump的文件

崩溃后的样子，可能不同的人写出来的形式不一样，或者弹出小窗，或者直接打印，或者发送监控消息给客户端，看自己实现吧！这里我采用直接打印:

调试开始前的准备：

这里的优化一定要关掉，否则会导致dunp文件里面的调试信息和代码对不上。

如果程序有可能产生windows底层的异常，这里也一定要切换

因为dump文件要和pdb一起使用，所以这里一定要生成pdb文件，否则一切白搭。

开始调试：
程序崩溃后，程序运行目录下面会生成dump文件，这个文件名由自己生成dump的函数决定。

这个时候，只需要用VS直接打开dump文件，就会进入到VS的调试界面

对着画线的部分，右键然后进入调试状态，这里两个选项可以随便选：

注意：如果这里出现一些识别不了的dll函数，就需要将对应的dll以及pdb拷贝过来，如果dll是操作系统里面的，只需要从微软的服务器下载就可以了。
这里弹出的框里面会提示异常的信息，指针指向的地方就是崩溃的位置。然后就和本地的程序调试一样，看各个值就可以了，这里不再赘述了。

Linux系统
调试开始前要准备的工作：开启生成核心文件（一次执行只对一个终端窗口有效，所以一旦终端关闭，就需要重新执行）
命令如下：
ulimit -c unlimited 这里是不限制core文件的大小，也可以限制core文件的大小，这个自行搜索吧！

代码如下：

 #include 
#include 

void main()
{
   int i = 0;
   char* pTmp = NULL;
   printf("%d\n", *pTmp);
   return;
}

编译，执行：

这里据说编译的时候必须加上-g 选项，否则用gdb调试的时候就会定位不到源代码，只能定位到二进制的地址。

运行程序以后，会在程序运行目录下生成一个core文件：

调试开始：

输入gdb 程序名 core文件名 就可以调试了，这里输出了一堆的信息，太多不想看？继续输入bt试试：

就这样可以定位到问题了。

通过对比还是可以发现linux下调试还是要比windows好用，不同的操作系统。dll都不一样，然后我们就必须拷dll到我们的输出目录下，很麻烦。就这样了，over。