记一次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 <stdio.h>
#include <stdlib.h>

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

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

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

调试开始： 输入gdb 程序名 core文件名 就可以调试了，这里输出了一堆的信息，太多不想看？继续输入bt试试： 就这样可以定位到问题了。

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