最后我所做的是在进程崩溃之前将gdb附加到进程，然后当它出现段错误时，我执行generate-core-file命令。强制生成核心转储。

还有更多的事情可能会影响核心转储的生成。我遇到了这些问题:

转储目录必须是可写的。默认情况下，这是进程的当前目录，但是可以通过设置/proc/sys/kernel/core_pattern来改变。 在某些情况下，/proc/sys/fs/suid_dumpable中的内核值可能会阻止内核的生成。

还有更多的情况可能会阻止手册页中描述的生成- try man核心。

最后我所做的是在进程崩溃之前将gdb附加到进程，然后当它出现段错误时，我执行generate-core-file命令。强制生成核心转储。

值得一提的是，如果你建立了一个系统，那么事情就会有点不同。通常情况下，通过core_pattern sysctl值将核心文件通过systemd-coredump(8)进行管道传输。核心文件大小rlimit通常已经配置为“unlimited”。

然后可以使用coredumpctl(1)检索核心转储。

coredump等的存储由coredump.conf(5)配置。在coredumpctl手册页中有一些如何获取核心文件的示例，但简而言之，它看起来像这样:

找到核心文件:

[vps@phoenix]~$ coredumpctl list test_me | tail -1
Sun 2019-01-20 11:17:33 CET   16163  1224  1224  11 present /home/vps/test_me

获取核心文件:

[vps@phoenix]~$ coredumpctl -o test_me.core dump 16163

Ubuntu 14.04

检查内核转储是否启用: ulimit - a 其中一行应该是: 核心文件大小(块，-c)不限 如果不是: 中~ /。在文件末尾添加ulimit -c unlimited并保存，重新运行终端。 使用调试信息构建应用程序: 在Makefile中-O0 -g 运行创建核心转储的应用程序(应该在application_name文件附近创建名为“core”的核心转储文件): 。/ application_name 在gdb下运行: GDB application_name core

这通常是足够的:

ulimit -c unlimited

注意，这不会在ssh部分之间持续存在!要添加持久性:

echo '* soft core unlimited' >> /etc/security/limits.conf

现在，如果你正在使用Ubuntu，“apport”可能正在运行。下面是检查方法:

sudo systemctl status apport.service

如果是，你可能会在以下位置之一找到核心转储:

/var/lib/apport/coredump 
/var/crash

如果您想更改核心转储的位置

确保您拥有创建文件的权限，并且该目录存在于您发送核心转储的目录中!

举个例子。注意，这将不会持续重启:

sysctl -w kernel.core_pattern=/coredumps/core-%e-%s-%u-%g-%p-%t
mkdir /coredumps

确保正在崩溃的进程有权写入该文件。最简单的方法是这样的例子:

chmod 777 /coredumps

测试内核转储是否工作

> crash.c
gcc -Wl,--defsym=main=0 crash.c
./a.out
==output== Segmentation fault (core dumped)

如果上面没有显示“核心转储”，说明有些东西不正常。