Linux 下的core文件

何为core 文件

当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。dump下来的信息就存储在core文件中。

如何产生core 文件

产生core文件的两种方法

1. 使用ulimit命令，只对当前终端环境有效
   使用ulimit -c命令可查看core文件的生成开关。若结果为0，则表示关闭了此功能，不会生成core文件。
   使用ulimit -c filesize命令，可以限制core文件的大小（filesize的单位为kbyte）。若ulimit -c unlimited，则表示core文件的大小不受限制。如果生成的信息超过此大小，将会被裁剪，最终生成一个不完整的core文件。在调试此core文 件的时候，gdb会提示错误。

2. 修改配置文件
   在/etc/profile中添加ulimit -S -c unlimited > /dev/null 2>&1，然后执行source /etc/profile,使配置生效

设置core文件的格式和路径

1. /proc/sys/kernel/core_uses_pid 可以控制产生的 core 文件的文件名中是否添加 pid 作为扩展 ，如果添加则文件内容为 1 ，否则为 0
2. proc/sys/kernel/core_pattern 可以设置格式化的 core 文件保存位置或文件名 ，比如原来文件内容是 core-%e
   可以这样修改：echo “/corefile/core-%e-%p-%t” > core_pattern
   将会控制所产生的 core 文件会存放到 /corefile 目录下，产生的文件名为 core- 命令名 -pid- 时间戳
   以下是参数列表 :

    %p - insert pid into filename 添加 pid
    %u - insert current uid into filename 添加当前 uid
    %g - insert current gid into filename 添加当前 gid
    %s - insert signal that caused the coredump into the filename 添加导致产生 core 的信号
    %t - insert UNIX time that the coredump occurred into filename 添加 core 文件生成时的 unix 时间
    %h - insert hostname where the coredump happened into filename 添加主机名
    %e - insert coredumping executable name into filename 添加命令名

可以产生 core 文件的信号

使用 kill -l 可以查看Linux上所有的信号，能产生core文件的主要有以下几种：

• SIGQUIT(3) 当用户在终端上按退出键（一般采用Ctrl-\）时，产生此信号，并送至前台进
• SIGILL (4)此信号指示进程已执行一条非法硬件指令
• SIGTRAP (5)指示一个实现定义的硬件故障
• SIGABRT(6) 调用abort函数时产生此信号。进程异常终止
• -SIGBUS(7) 指示一个实现定义的硬件故障
• SIGFPE(8) 此信号表示一个算术运算异常，例如除以0，浮点溢出等
• SIGSEGV(11) 指示进程进行了一次无效的存储访问
• SIGXCPU(24) SVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制，则产生此信号
• SIGXFSZ(25) 如果进程超过了其软文件长度限制，则SVR4和4.3+BSD产生此信号
• SIGIOT (29) 这指示一个实现定义的硬件故障
• SIGSYS (31)指示一个无效的系统调用。由于某种未知原因，进程执行了一条系统调用指令,但其指示系统调用类型的参数却是无效的

直接输入指令 :kill -s SIGSEGV $$，可以测试下是否会产生core文件

core 文件的使用

当core dump 之后，使用命令 gdb program core 来查看 core 文件，其中 program 为可执行程序名，core 为生成的 core 文件名。

参考

• [1]： https://www.cnblogs.com/Anker/p/6079580.html
• [2]： https://blog.csdn.net/u011417820/article/details/71435031/