在linux下，程序莫名突然崩溃了怎么办，有的程序有日志，有的程序没有则么办，或者自己忘记定义了怎么办，而且，有没有其他途径能配合程序日志更快的解决问题？
基本概念： 当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中，这种行为就叫做Core Dump（中文有的翻译成“核心转储”)。我们可以认为 core dump 是“内存快照”，但实际上，除了内存信息之外，还有些关键的程序运行状态也会同时 dump 下来，例如寄存器信息（包括程序指针、栈指针等）、内存管理信息、其他处理器和操作系统状态和信息。core dump 对于编程人员诊断和调试程序是非常有帮助的，因为对于有些程序错误是很难重现的，例如指针异常，而 core dump 文件可以再现程序出错时的情景。
查看系统的core功能是否打开：
[root@VM_13_117_centos security]# 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) 128337
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 100001
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 128337
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
参数 描述
ulimited 不限制用户可以使用的资源，但本设置对可打开的最大文件数（max open files）
和可同时运行的最大进程数（max user processes）无效
-a 列出所有当前资源极限
-c 设置core文件的最大值.单位:blocks
-d 设置一个进程的数据段的最大值.单位:kbytes
-f Shell 创建文件的文件大小的最大值，单位：blocks
-h 指定设置某个给定资源的硬极限。如果用户拥有 root 用户权限，可以增大硬极限。任何用户均可减少硬极限
-l 可以锁住的物理内存的最大值
-m 可以使用的常驻内存的最大值,单位：kbytes
-n 每个进程可以同时打开的最大文件数
-p 设置管道的最大值，单位为block，1block=512bytes
-s 指定堆栈的最大值：单位：kbytes
-S 指定为给定的资源设置软极限。软极限可增大到硬极限的值。如果 -H 和 -S 标志均未指定，极限适用于以上二者
-t 指定每个进程所使用的秒数,单位：seconds
-u 可以运行的最大并发进程数
-v Shell可使用的最大的虚拟内存，单位：kbytes
在linux中，我们可以用ulimit -a指令来查看，哪些系统设置被限制了，要么开关，要么限制大小，要么无限制，总共三种方案。
开启core dump功能：执行指令： ulimit -c unlimited
这个命令只对当前终端有效，要想永久有效，修改配置文件/etc/security/limits.conf，格式如下：
* soft core unlimited
* soft nofile 100001
* hard nofile 100002
root soft nofile 100001
root hard nofile 100002
修改core文件路径：
默认生成的core文件保存在与可执行文件的同级目录下，名字就叫core；
通过修改/proc/sys/kernel/core_uses_pid : echo 1 > /proc/sys/kernel/core_uses_pid 就可以让生成的core文件名加上pid，其中pid为该挂掉进程的pid，那么这里，当有很多个进程同时存在的时候，哪个进程挂了，对应的core文件就会以该进程的PID作为文件后缀,形似：“core.PID”
通过修改/proc/sys/kernel/core_pattern开控制生成的core文件的位置以及文件名格式
echo "/tmp/corefile-%e-%p-%t" > /proc/sys/kernel/core_pattern
上面的配置的作用为将core文件保存在/tmp/corefile目录中，且格式为："core-命令名-pid-时间戳"；
犀牛的服务器中/proc/sys/kernel/core_pattern 内容为core，则说明，保存在默认位置，无特殊格式，但/proc/sys/kernel/core_uses_pid中为1，所以pid是有的，同时也在程序的bin目录下发现core文件，说明解释正确。
网上用了一段代码调试core，这里就不涉及了，但是打开core文件中格式是乱码的，因为要用GDB去调用core文件，当core dump之后，要用gdb program corename来查看core文件，其中program为可调用程序名，corename为生成的core文件名。
core文件的使用：
在core文件所在目录下键入:
gdb -c core （-c指定core文件）
它会启动GNU的调试器，来调试core文件，并且会显示生成此core文件的程序名，中止此程序的信号等等
如果你已经知道是由什么程序生成此core文件的，比如MyServer崩溃了生成core.12345，那么用此指令调试:
gdb ./mysql core
以犀牛的例子为准：
[root@VM_200_97_centos bin]# gdb ./sdo_security -d core.22624
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
warning: /app/sdo/server/bin/core.22624 is not a directory.
Reading symbols from /app/sdo/server/bin/sdo_security...done.
(gdb)
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `./sdo_security -d‘.
Program terminated with signal 6, Aborted.
#0 0x00007fe3c8ceb625 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.x86_64 libgcc-4.4.7-16.el6.x86_64 libstdc++-4.4.7-16.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) quit
这里截取了最后几行，其中最后面的Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.x86_64 libgcc-4.4.7-16.el6.x86_64 libstdc++-4.4.7-16.el6.x86_64 zlib-1.2.3-29.el6.x86_64
这里有个调试依赖的报错，提示你直接执行这个语句，也就是安装后面的那几个包，这里不做阐述。
core在C环境下的程序中常常用到！共勉。
