本文中的操作系统版本：CentOS Linux release 7.7.1908 (Core)
一、什么是Core Dump文件？
开发和使用Linux程序时, 有时程序（进程）莫名其妙的异常终止或者崩溃挂掉或者异常退出了, 却没有任何的提示，让开发者感觉很莫名其妙 丈二和尚摸不着头脑 根本无法定位程序是哪里出现了问题 debug都不知道该从哪里进行debug，怎么办？
这时候我们可以使用Linux提供的core dump机制。程序（进程）莫名其妙的异常终止或者异常崩溃挂掉的时候，就会形成核心文件（core.进程号 的文件），这个生成的core文件记录了程序（进程）在挂掉时的内存内容, 它可以做为我们调试程序的参考。然后我们就可以使用gdb工具对产生的core文件进行分析，找出程序（进程）是在什么时候崩溃的 和 在崩溃之前程序（进程）都做了些什么。
core dump中文翻译为“核心转储”。可以理解为Core Dump是“内存快照”。实际上，除了内存信息之外，还有些关键的程序运行状态也会同时被dump下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其它处理器和操作系统状态等信息。
看官：这么多废话，简单点！！！ 咳咳^_^ 暴躁小哥哥~~~ 别急嘛= = 下面给您整一句话总结：
当程序运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump
二、如何开启Core Dump？
2.1、查看当前系统是否开启了core dump
# ulimit -a 命令查看是否开启了core dump [root@izm5e8vp7zjro140az4o97z ~] ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7269 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65535 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 65535 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
上面的 core file size 这一选项后面是0 表示没有开启
2.1、临时开启core dump，只在当前终端有效
# ulimit -c unlimited 临时在当前终端开启core dump，并且设置生成的core dump文件的大小不受限制，如果你需要限制文件的大小，将unlimited改成你想生成core文件最大的大小，注意单位为blocks(KB) [root@izm5e8vp7zjro140az4o97z ~] ulimit -c unlimited # 再次使用ulimit -a 命令 发现 core file size 选项后面的值是unlimited 表示已经开启成功 [root@izm5e8vp7zjro140az4o97z ~] ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7269 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65535 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 65535 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
查看是否开启了core功能除了使用ulimit -a命令之外，还可以使用ulimit -c，在终端中输入命令 ulimit -c ，输出的结果为0，说明当前是关闭 core dump 的，即当程序异常终止时，也不会生成 core dump 文件
2.1、永久开启core dump
①、在/etc/profile文件中的末尾 添加ulimit -c unlimited 然后保存退出
②、使用 source /etc/profile 命令让配置生效
③、新打开的终端 使用相关命令查看core dump功能会发现都是开启的
三、生成Core Dump文件的存放目录和命名规则（本文中就不设置了）
①、/proc/sys/kernel/core_uses_pid 该文件可以控制产生的 core 文件的文件名中是否添加 pid（进程号） 作为扩展，如果添加则文件内容为 1（默认为 1 ） ，否则为 0
②、/proc/sys/kernel/core_pattern 该文件可以设置生成的 core 文件保存位置或文件名 ，比如原来文件内容是core
可以这样修改：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 Dump文件
调试core文件需要借助一个叫gdb的工具，如果你在终端输入gdb命令后 按回车键提示 -bash: gdb: command not found 那么需要先安装gdb工具。
Centos系统使用：yum -y install gdb 使用yum直接一键安装gdb，其它操作系统请自行安装
gdb调试工具的使用方式如下：
gdb -c core文件路径 [应用程序的路径] # 比如：gdb -c core.31039 /usr/bin/php
4.1模拟生成core文件（已开启core dump功能，且使用的是默认的core dump设置），然后进行调试：
①、在/home/wwwroot/default/practice目录下 写一个demo1.php文件，文件内容如下：
<?php
echo 123;
while(1)
{
}②、在终端使用 php ./demo1.php 运行该文件，会发现该终端已经卡住了，此时我们使用ctrl + c 让该程序（进程）终止，然后会发现在/home/wwwroot/default/practice目录下 发生成了一个core.31039文件，31039 就是这个程序在运行的时候，产生的进程号（进程id），具体视个人情况而定，每个人差生的进程号肯定都是不一样的
PS：core文件生成的位置一般位于 运行程序的路径相同，文件名一般为 core.进程号（PS：如果你没有更改core dump默认生成文件的规则的话）
③、使用gdb工具进行调试core.31039文件
由于程序在运行中 数据都是以二进制的形式存放在内存的，所以 直接用vim或者cat查看该文件会发现都是一堆乱码，所以我们需要借助使用gdb工具进行查看和调试
gdb -c core.31039 /usr/bin/php
进去后输入where或者bt 然后按回车，就可以显示程序在哪一行当掉的, 在哪个函数中等之类的报错信息
声明：禁止任何非法用途使用，凡因违规使用而引起的任何法律纠纷，本站概不负责。
精彩评论