core dump

Core dump定义

core dump又叫核心转储, 当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump.
查看core dump信息，可在linux系统终端内输入命令：man core dump，以下截取部分内容，
Linux man pages ——core - core dump file

The default action of certain signals is to cause a process to terminate and produce acore dump file, a disk file containing an image of the process's memory at the time of termination. This image can be used in a debugger (e.g., gdb) to inspect the state of the program at the time that it terminated. A list of the signals which cause a process to dump core can be found in signal.
*

A process can set its soft RLIMIT_CORE resource limit to place an upper limit on the size of the core dump file that will be produced if it receives a "core dump" signal; see getrlimit for details.

There are various circumstances in which a core dump file is not produced:

The process does not have permission to write the core file. (By default the core file is called core, and is created in the current working directory. See below for details on naming.) Writing the core file will fail if the directory in which it is to be created is nonwritable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link).

A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file.

*

The file system where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the file system.

*

The directory in which the core dump file is to be created does not exist.

*

The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell's ulimitcommand (limit in csh(1)).

*

The binary being executed by the process does not have read permission enabled.

*

The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process. (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).)

*

(Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option.

In addition, a core dump may exclude part of the address space of the process if the madvise(2) MADV_DONTDUMP flag was employed.

Core文件的命名和路径

默认情况下core文件名即为"core"，文件路径：运行可执行文件时，环境所在的目录

coredump的路径和格式：
　　修改配置文件/etc/sysctl.conf(重启后生效)
　　kernel.core_pattern = core
　　kernel.core_uses_pid = 1

两个控制文件

(1)    /proc/sys/kernel/core_uses_pid

             0: 默认值，生成的文件名不会带上PID后缀

             1: 文件名带上PID后缀，如"core.2976"

         修改方法： "echo 1 > /proc/sys/kernel/core_uses_pid"

(2)  /proc/sys/kernel/core_pattern

            用来控制文件名格式

            默认值： core   

            假设将其值改变为："/home/duanbei/corefile/core-%e-%p-%t"， 那么所有的core文件将保存在"/home/duanbei/corefile"目录下，文件名格式为“core-程序名-pid-时间戳”

Core文件产生相关信号

core文件产生一般都因软件异常挂死，程序接收到以下UNIX信号会产生core文件：

名字	说明	ANSI C  POSIX.1	SVR4  4.3+BSD	缺省动作
SIGABRT	异常终止(abort)	.       .	.      .	终止w/core
SIGBUS	硬件故障	.	.      .	终止w/core
SIGEMT	硬件故障		.      .	终止w/core
SIGFPE	算术异常	.       .	.      .	终止w/core
SIGILL	非法硬件指令	.       .	.      .	终止w/core
SIGIOT	硬件故障		.      .	终止w/core
SIGQUIT	终端退出符	.	.      .	终止w/core
SIGSEGV	无效存储访问	.       .	.      .	终止w/core
SIGSYS	无效系统调用		.      .	终止w/core
SIGTRAP	硬件故障		.      .	终止w/core
SIGXCPU	超过CPU限制(setrlimit)		.      .	终止w/core
SIGXFSZ	超过文件长度限制(setrlimit)		.      .	终止w/core

在系统默认动作列，“终止w/core”表示在进程当前工作目录的core文件中复制了该进程的存储图像（该文件名为core，由此可以看出这种功能很久之前就是UNIX功能的一部分）。大多数UNIX调试程序都使用core文件以检查进程在终止时的状态。

core文件的产生不是POSIX.1所属部分,而是很多UNIX版本的实现特征。UNIX第6版没有检查条件(a)和(b)，并且其源代码中包含如下说明：“如果你正在找寻保护信号，那么当设置-用户-ID命令执行时，将可能产生大量的这种信号”。4.3 + BSD产生名为core.prog的文件，其中prog是被执行的程序名的前1 6个字符。它对core文件给予了某种标识，所以是一种改进特征。

表中“硬件故障”对应于实现定义的硬件故障。这些名字中有很多取自UNIX早先在DP-11上的实现。请查看你所使用的系统的手册，以确切地确定这些信号对应于哪些错误类型。

下面比较详细地说明这些信号。

? SIGABRT 调用abort函数时产生此信号。进程异常终止。

? SIGBUS  指示一个实现定义的硬件故障。

? SIGEMT  指示一个实现定义的硬件故障。

EMT这一名字来自PDP-11的emulator trap 指令。

? SIGFPE  此信号表示一个算术运算异常，例如除以0，浮点溢出等。

? SIGILL  此信号指示进程已执行一条非法硬件指令。

4.3BSD由abort函数产生此信号。SIGABRT现在被用于此。

? SIGIOT  这指示一个实现定义的硬件故障。

IOT这个名字来自于PDP-11对于输入／输出TRAP(input/output TRAP)指令的缩写。系统V的早期版本，由abort函数产生此信号。SIGABRT现在被用于此。

? SIGQUIT 当用户在终端上按退出键（一般采用Ctrl-\）时，产生此信号，并送至前台进

程组中的所有进程。此信号不仅终止前台进程组（如SIGINT所做的那样），同时产生一个core文件。

? SIGSEGV 指示进程进行了一次无效的存储访问。

名字SEGV表示“段违例（segmentation violation）”。

? SIGSYS  指示一个无效的系统调用。由于某种未知原因，进程执行了一条系统调用指令，

但其指示系统调用类型的参数却是无效的。

? SIGTRAP 指示一个实现定义的硬件故障。

此信号名来自于PDP-11的TRAP指令。

? SIGXCPU SVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制，则产生此信号。

? SIGXFSZ 如果进程超过了其软文件长度限制，则SVR4和4.3+BSD产生此信号。

摘自《UNIX环境高级编程》第10章 信号。

Core文件系统设置

系统默认core文件的大小为0，及不会创建core文件。可以用ulimit命令查看和修改core文件的大小。
ulimit -c 0
ulimit -c 1000
ulimit -c 1000

-c 指定修改core文件的大小，1000指定了core文件大小。也可以对core文件的大小不做限制，如：

ulimit -c unlimited

如果想让修改永久生效，则需要修改配置文件，如 /etc/profile或/etc/security/limits.conf。

Core文件调试

core文件是个二进制文件，需要用相应的工具来分析程序崩溃时的内存映像。

在Linux下可以用GDB来调试core文件。

格式：gdb 程序名称 core文件名

gdb core_dump_test core.6133

GDB中键入where，就会看到程序崩溃时堆栈信息（当前函数之前的所有已调用函数的列表（包括当前函数），gdb只显示最近几个），我们很容易找到我们的程序在最后崩溃的时候调用了core_dump_test.c 第7行的代码，导致程序崩溃。注意：在编译程序的时候要加入选项-g。您也可以试试其他命令，　如　fram、list等。更详细的用法，请查阅GDB文档。