我有一个进程在Linux得到一个分割错误。当它失败时，我如何告诉它生成一个核心转储?
当前回答
要检查内核转储是在哪里生成的，运行:
sysctl kernel.core_pattern
or:
cat /proc/sys/kernel/core_pattern
其中%e为进程名，%t为系统时间。您可以在/etc/sysctl.conf中修改它，并通过sysctl -p重新加载。
如果没有生成核心文件(通过:sleep 10 &和killall -SIGSEGV sleep进行测试)，则通过:ulimit -a检查限制。
如果你的核心文件大小有限，运行:
ulimit -c unlimited
让它无限。
然后再次测试，如果核心转储成功，你会看到“(核心转储)”分割故障指示如下:
分段故障:11(核心转储)
请参见:核心转储-但核心文件不在当前目录?
Ubuntu
在Ubuntu中，核心转储由Apport处理，可以位于/var/crash/。但是，在稳定版本中默认禁用它。
更多细节，请查看:我在哪里找到Ubuntu的核心转储?
操作系统
对于macOS，请参阅:如何在Mac OS X中生成核心转储?
其他回答
值得一提的是，如果你建立了一个系统，那么事情就会有点不同。通常情况下，通过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
如上所述，这里提出的真正问题是如何在未启用核心转储的系统上启用它们。这个问题在这里得到了解答。
如果您希望了解如何为挂起进程生成核心转储，那么答案是
gcore <pid>
如果gcore在您的系统上不可用，那么
kill -ABRT <pid>
不要使用kill -SEGV，因为它经常会调用信号处理程序，使诊断卡住进程更加困难
要检查内核转储是在哪里生成的，运行:
sysctl kernel.core_pattern
or:
cat /proc/sys/kernel/core_pattern
其中%e为进程名，%t为系统时间。您可以在/etc/sysctl.conf中修改它，并通过sysctl -p重新加载。
如果没有生成核心文件(通过:sleep 10 &和killall -SIGSEGV sleep进行测试)，则通过:ulimit -a检查限制。
如果你的核心文件大小有限，运行:
ulimit -c unlimited
让它无限。
然后再次测试，如果核心转储成功，你会看到“(核心转储)”分割故障指示如下:
分段故障:11(核心转储)
请参见:核心转储-但核心文件不在当前目录?
Ubuntu
在Ubuntu中，核心转储由Apport处理，可以位于/var/crash/。但是，在稳定版本中默认禁用它。
更多细节，请查看:我在哪里找到Ubuntu的核心转储?
操作系统
对于macOS，请参阅:如何在Mac OS X中生成核心转储?
最后我所做的是在进程崩溃之前将gdb附加到进程，然后当它出现段错误时，我执行generate-core-file命令。强制生成核心转储。
这取决于您使用的shell。如果使用bash，则ulimit命令控制与程序执行相关的几个设置，例如是否应该转储core。如果你输入
ulimit -c unlimited
然后这将告诉bash，它的程序可以转储任何大小的内核。如果你愿意，你可以指定一个大小，比如52M，而不是无限，但在实践中，这不应该是必要的，因为核心文件的大小可能永远不会成为你的问题。
在tcsh中，您需要输入
limit coredumpsize unlimited
