4. 如何自定义core文件名和目录
（1） /proc/sys/kernel/core_uses_pid 可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0。如果添加了pid，生成的core文件一般为core.xxx（xxx为core dump的进程号）。默认为0，即不添加进程pid.
（2） /proc/sys/kernel/core_pattern 可以设置格式化的core文件保存位置或文件名，比如我的系统的默认值为：
|/usr/share/apport/apport %p %s %c %P
1
|/usr/share/apport/apport %p %s %c %P
我们可以使用以下命令修改此文件：
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 添加命令名
5. 如何查看core文件
我们可以使用gdb来查看core文件（core文件必须是完好的，比如如果我们限制的core文件大小比较小，导致core文件被截断，则gdb查看时将出错）。查看语法如下：
gdb [exec file] [core file]
比如： gdb ./test core.3937 。gdb进去以后，可以使用bt或where来查看进程崩溃之前的堆栈信息。
6. 一些注意事项
在Linux下要保证程序崩溃时生成Coredump要注意这些问题：
要保证存放Coredump的目录存在且进程对该目 录有写权限。存放Coredump的目录即进程的当前目录，一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动，则脚本可能会修改当前目 录，这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/<进程pid>/cwd“符号链接的目标来确定进程 真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。
若程序调用了seteuid()/setegid()改变 了进程的有效用户或组，则在默认情况下系统不会为这些进程生成Coredump。很多服务程序都会调用seteuid()，如MySQL，不论你用什么用 户运行mysqld_safe启动MySQL，mysqld进行的有效用户始终是msyql用户。如果你当初是以用户A运行了某个程序，但在ps里看到的 这个程序的用户却是B的话，那么这些进程就是调用了seteuid了。为了能够让这些进程生成core dump，需要将/proc/sys/fs /suid_dumpable文件的内容改为1（一般默认是0）。
这个一般都知道，就是要设置足够大的Core文件大小限制 。程序崩溃时生成的Core文件大小即为程序运行时占用的内存大小。但程序崩溃时的行为不可按平常时的行为来估计，比如缓冲区溢出等错误可能导致堆栈被 破坏，因此经常会出现某个变量的值被修改成乱七八糟的，然后程序用这个大小去申请内存就可能导致程序比平常时多占用很多内存。因此无论程序正常运行时占用 的内存多么少，要保证生成Core文件还是将大小限制设为unlimited为好。
