linux应用程序如何自己控制coredump生成

解决如何让应用程序控制core文件的产生

core文件生成设置

1. 使用系统配置
2. 使用部分程序控制，部分系统配置
3. 完全程序控制，coredumper实践

系统配置core生成

1. 开启core产生
   ulimit -c unlimited
2. 配置core路径
   默认进程的工作目录下，通过chdir可以更改。
   配置路径 /proc/sys/kernel/core_pattern

缺陷，应用程序是否产生core完全依赖系统配置。

部分程序控制，部分系统配置

1. 使用setrlimit函数设置进程产生的core文件大小
2. 使用chdir控制进程的工作目录，用以在默认core产生的配置下能够在chdir指定的路径下产生core文件。
3. prctl设置程序可产生core文件

缺陷，应用程序产生core文件路径依赖系统配置，如果反复产生core则可能导致磁盘打满。

完全应用程序控制

方案如，google coredumper开源代码，github上可以获取到。这种方式完全由应用程序自己监听挂机信号，在信号中获取进程信息，自己生成core文件，不依赖系统内核的任何配置。

优点，完全可控，产生core的位置，core文件名可以自己控制。

内核如何产生core？

程序挂机时会有相应的信号发出，该信号默认的处理动作在内核中会进入core文件生成的流程中。
在识别信号需要产生core则进一步判断系统的core文件ulimit设置以及获取系统配置的core文件位置和core文件名字，最终产生core。

综上，如果我们自己程序中注册监听了挂机信号，内核还能产生core吗？
答案，肯定不能，只有触发挂机信号的默认动作在内核中会产生。而自己处理了信号就不执行默认的动作了。

应用程序如何完全自己控制产生core

基本原理就是监听这些触发挂机的信号，在挂机信号处理中收集进程信息，产生core。具体内部还挺复杂，可以参考google coredumper开源代码。

google coredumper问题

如何用？源码编译

gcc -g test_core.c coredumper-1.2.1/src/coredumper.c coredumper-1.2.1/src/elfcore.c coredumper-1.2.1/src/linuxthreads.c -I coredumper-1.2.1/src/ -znorelro

如何用？引用库

下载coredumper后执行以下命令安装
configure
make
make install

然后使用
gcc test_core.c -g -lcoredumper -L /usr/local/lib/ -znorelro

踩坑

CLONE_VM错误

在报该错误的 .c 文件头添加如下两行代码，注意必须在报错的.c中，而不是其他包含的头文件中
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <sched.h>

产生的core文件有问题

具体表现就是，按照命令编译了程序，程序执行产生了core。但该core通过gdb调试时发现有问题？bt一看一脸懵逼啥都没有，一堆？？

这种是编译的时候需要带-znorelro