Linux core dump有什么用？

进程崩溃时，Linux会将崩溃前进程的内存状态保存在core文件里，就像保存了案发现场的照片，可以帮助开发人员找到事故原因，修复程序。本文用简单的例子讲解如何根据core文件，定位进程崩溃的原因。 首先编写C++代码，定义一个空指针，对空指针所指向的内存区域写，发生段错误

coretest01.cpp

#include<stddef.h>int main(){    
    int *p = NULL;        
    *p = 10;
}

编译出可执行文件coretest01，运行打印出core dumped，应该出现core文件。

但是在目录下并没有产生core文件，这是系统设置禁止了文件产生。

用ulimit -a查看系统对core文件的设置

core file size设置是0，也就是不允许core文件产生。

修改配置，改为unlimited，对大小不做限制。

执行coretest01，产生了core文件，后面的数字是崩溃进程的进程号。

查看core文件信息使用gdb命令，

[root@webserver code]# gdb coretest01 core.1953

gdb下执行bt和where可以看见令程序崩溃的代码位置，但是现在只能看见main函数，看不见其它具体信息。这是因为编译代码时没有加入调试信息，g++加入调试信息的参数是-g

可以看到加入调试信息后，core文件能准确的告知出错代码的文件和在第几行，第5行正是代码对空指针指向区域写操作的地方

实际生产系统往往很多可执行文件在同一个目录，aserver bserver......等等。当出现core文件时，我们首先要判断core文件由哪个可执行文件产生，然后才能排查问题。命令file core可以帮助我们判断core是哪个可执行文件产生的。

再写个代码文件coretest02.cpp

#include<stddef.h>int main(){   
     int *p2 = NULL;        
     *p2 = 10;
}

编译生成可执行文件coretest02，运行两个可执行文件，会出现两个core文件

file core.* 可以正确指出core文件出自哪个可执行文件（无论可执行文件是什么，哪怕是java，Python，都是一样的操作），然后gdb 可执行文件 core.*，可以查看错误原因。