linux 崩溃文件 coredump 简介

比眉伴天荒 2021-08-28 18:16 814阅读 0赞

**目录**

1、什么是coredump

2、开启或关闭core文件的生成

3、造成程序core的原因

4、用GDB调试coredump

--------------------

### 1、什么是coredump ###

我们经常听到大家说到程序core掉了，需要定位解决，这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止，并且在满足一定条件下会产生一个叫做core的文件。  
    通常情况下，core文件会包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理信息还有各种函数调用堆栈信息等，我们可以理解为是程序工作当前状态存储生成的一个文件，许多的程序出错的时候都会产生一个core文件，通过工具分析这个文件，我们可以定位到程序异常退出的时候对应的堆栈调用等信息，找出问题所在并进行及时解决。

### 2、开启或关闭core文件的生成 ###

（1）查看core文件是否打开：

ulimit -c  # 如果为 0 表示coredump开关处于关闭状态

（2）打开core文件生成：

ulimit -c 1024 # 1024个blocks,一般1block=512bytes
    ulimit -c unlimited # 取消大小限制

（3）检查core文件的选项是否打开：

ulimit -a  # 显示当前所有limit信息

> `命令参数     描述     例子`
> 
> `-H    设置硬资源限制，一旦设置不能增加。     ulimit – Hs 64；限制硬资源，线程栈大小为 64K。`
> 
> `-S    设置软资源限制，设置后可以增加，但是不能超过硬资源设置。  ulimit – Sn 32；限制软资源，32 个文件描述符。`
> 
> `-a    显示当前所有的 limit 信息     ulimit – a；显示当前所有的 limit 信息`
> 
> `-c    最大的 core 文件的大小， 以 blocks 为单位     ulimit – c unlimited； 对生成的 core 文件的大小不进行限制`
> 
> `-d    进程最大的数据段的大小，以 Kbytes 为单位     ulimit -d unlimited；对进程的数据段大小不进行限制`
> 
> `-f    进程可以创建文件的最大值，以 blocks 为单位     ulimit – f 2048；限制进程可以创建的最大文件大小为 2048 blocks`
> 
> `-l    最大可加锁内存大小，以 Kbytes 为单位     ulimit – l 32；限制最大可加锁内存大小为 32 Kbytes`
> 
> `-m    最大内存大小，以 Kbytes 为单位     ulimit – m unlimited；对最大内存不进行限制`
> 
> `-n    可以打开最大文件描述符的数量     ulimit – n 128；限制最大可以使用 128 个文件描述符`
> 
> `-p    管道缓冲区的大小，以 Kbytes 为单位     ulimit – p 512；限制管道缓冲区的大小为 512 Kbytes`
> 
> `-s    线程栈大小，以 Kbytes 为单位     ulimit – s 512；限制线程栈的大小为 512 Kbytes`
> 
> `-t    最大的 CPU 占用时间，以秒为单位     ulimit – t unlimited；对最大的 CPU 占用时间不进行限制`
> 
> `-u    用户最大可用的进程数     ulimit – u 64；限制用户最多可以使用 64 个进程`
> 
> `-v    进程最大可用的虚拟内存，以 Kbytes 为单位     ulimit – v 200000；限制最大可用的虚拟内存为 200000 Kbytes`

（4） 永久配置core：

以上配置只对当前会话起作用，下次重新登陆后，还是得重新配置。要想配置永久生效，得在**/etc/profile**或者**/etc/security/limits.conf**文件中进行配置。

1）第一种方式：首先打开/etc/profile文件，一般都可以在文件中找到这句语句：**ulimit -S -c 0 > /dev/null 2>&1**，根据上面的例子，我们只要把那个0 改为 unlimited 就ok了。然后保存退出。通过**source /etc/profile** 使当期设置生效。或者想配置只针对某一用户有效，则修改此用户的~/.bashrc或者~/.bash\_profile文件：

limit -c unlimited

2）第二种方式：第二种方法可以通过修改/etc/security/limits.conf文件来设置，首先以root权限登陆，然后打开/etc/security/limits.conf文件，进行配置：

#vim /etc/security/limits.conf
    <domain> <type> <item> <value>
    * soft core unlimited

3、core文件的存储位置和文件名

（1）存储位置：

core文件默认的存储位置与对应的可执行程序在同一目录下，文件名是core，可以通过下面的命令看到core文件的存在位置：

cat  /proc/sys/kernel/core_pattern  # 缺省值是|/usr/share/apport/apport %p %s %c %P

**    注意：**这里是指在进程当前工作目录的下创建。通常与程序在相同的路径下。但如果程序中调用了chdir函数，则有可能改变了当前工作目录。这时core文件创建在chdir指定的路径下。有好多程序崩溃了，我们却找不到core文件放在什么位置。和chdir函数就有关系。当然程序崩溃了不一定都产生 core文件。

更改coredump文件的存储位置：

echo “/data/coredump/core”> /proc/sys/kernel/core_pattern  # 把core文件生成到/data/coredump/core目录下

（2）core文件的命名：

缺省情况下，内核在coredump时所产生的core文件放在与该程序相同的目录中，并且文件名固定为*core*。很显然，如果有多个程序产生core文件，或者同一个程序多次崩溃，就会重复覆盖同一个core文件，因此我们有必要对不同程序生成的core文件进行分别命名。

1）/proc/sys/kernel/core\_uses\_pid可以控制core文件的文件名中是否添加pid作为扩展。文件内容为1，表示添加pid作为扩展名，生成的core文件格式为core.xxxx；为0则表示生成的core文件同一命名为core。可通过以下命令修改此文件：

echo "1" > /proc/sys/kernel/core_uses_pid

2）/proc/sys/kernel/core\_pattern可以控制core文件保存位置和文件名格式，可通过以下命令修改此文件：

echo "/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern # 可以将core文件统一生成到/corefile目录下，产生的文件名为core-命令名-pid-时间戳

以下是参数列表：

> `%% - 单个%字符`
> 
> `%p - 添加pid`
> 
> `%u - 添加当前uid`
> 
> `%g - 添加当前gid`
> 
> `%s - 添加导致产生core的信号`
> 
> `%t - 添加core文件生成时的unix时间`
> 
> `%h - 添加主机名`
> 
> `%e - 添加程序文件名 `

### 3、造成程序core的原因 ###

造成程序coredump的原因有很多，这里总结一些比较常用的经验吧：

（1）内存访问越界：  
   a) 由于使用错误的下标，导致数组访问越界。  
   b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符。  
   c) 使用strcpy, strcat, sprintf, strcmp,strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

（2）多线程程序使用了线程不安全的函数：  
      应该使用下面这些可重入的函数，它们很容易被用错：

>     asctime\_r(3c) 、gethostbyname\_r(3n) 、getservbyname\_r(3n)、ctermid\_r(3s) 、gethostent\_r(3n) 、getservbyport\_r(3n)、 ctime\_r(3c) 、getlogin\_r(3c)、getservent\_r(3n) 、fgetgrent\_r(3c) 、getnetbyaddr\_r(3n) 、getspent\_r、(3c)fgetpwent\_r、(3c) getnetbyname\_r(3n)、 getspnam\_r(3c)、 fgetspent\_r(3c)、getnetent\_r(3n) 、gmtime\_r(3c)、 gamma\_r(3m) 、getnetgrent\_r(3n) 、lgamma\_r(3m) 、getauclassent\_r(3)、getprotobyname\_r(3n) 、localtime\_r(3c) 、getauclassnam\_r(3) 、etprotobynumber\_r(3n)、nis\_sperror\_r(3n) 、getauevent\_r(3) 、getprotoent\_r(3n) 、rand\_r(3c) 、getauevnam\_r(3)、getpwent\_r(3c) 、readdir\_r(3c) 、getauevnum\_r(3) 、getpwnam\_r(3c) 、strtok\_r(3c)、 getgrent\_r(3c)、getpwuid\_r(3c) 、tmpnam\_r(3s) 、getgrgid\_r(3c) 、getrpcbyname\_r(3n)、 ttyname\_r(3c)、getgrnam\_r(3c) 、getrpcbynumber\_r(3n) 、gethostbyaddr\_r(3n) 、getrpcent\_r(3n)

（3）多线程读写的数据未加锁保护：

对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成coredump。

（4）非法指针：

a) 使用空指针；  
    b) 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump。

（5）堆栈溢出：  
    不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

### 4、用GDB调试coredump ###

其实分析coredump的工具有很多，现在大部分类unix系统都提供了分析coredump文件的工具，不过，我们经常用到的工具是gdb。 这里我们以程序为例子来说明如何进行定位，使用gdb调试core文件来查找程序中出现段错误的位置时，要注意的是可执行程序在编译的时候需要加上**-g**编译命令选项。

（1）core.cpp的文件如下：

#include <stdio.h>
    
    void core_test1()
    {
        int i = 0;
    
        scanf("%d", i);
        printf("%d\n", i);
    }
    
    void core_test2()
    {
        char *ptr = "my name is hello world";
    
        *ptr = 0;
    }
    
    int main()
    {
        core_test1();
        return 0;
    }

编译：

g++ -g core.cpp -o test

运行：

./test
    12
    Segmentation fault (core dumped) # 可以看到，当输入12的时候，系统提示段错误并且core dumped

（2）判断是否为core文件：

在类unix系统下，coredump文件本身主要的格式也是ELF格式，可以通过简单的file命令进行快速判断：

file core.xxxxx
    输出：
    core.11691: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './test'

（3）使用GDB调试

**第一种方法（推荐）：**  
    1）启动gdb，进入core文件，命令格式：gdb \[exec file\] \[core file\]，用法示例：

gdb ./test core.xxxxx

2）在进入gdb后，查找段错误位置：where或者bt，用法示例：

bt
    #0 0x00007f205b7afde5 in _IO_vfscanf_internal (s=<optimized out>, format=<optimized out>, argptr=argptr@entry=0x7ffdf417be88,
    errp=errp@entry=0x0) at vfscanf.c:1902
    #1 0x00007f205b7ba87b in __scanf (format=<optimized out>) at scanf.c:33
    #2 0x0000000000400589 in core_test1 () at core.cpp:5
    #3 0x00000000004005bf in main () at core.cpp:15

**第二种方法：**  
    1）启动gdb，进入core文件，命令格式：

gdb -c [core file]  //或 gdb --core=[core file]

（2）在进入gdb后，指定core文件对应的符号表，命令格式：

(gdb) file [exec file]

（3）查找段错误位置：where或者bt。用法示例：