一行代码获取最新的核心转储路径:

ls -t $(cat /proc/sys/kernel/core_pattern | awk -F% '{print $1"*"}') 2>/dev/null | head -1

当然，您可以将该行的最后一个-1修改为-4，以获得最后4个核心转储。

注意:如果路径模式在最后一个/之前使用变量，或者当非核心转储文件在该目录下时，这并不预期会起作用。

编写在Ubuntu 16.04 LTS下获得核心转储的指令:

As @jtn has mentioned in his answer, Ubuntu delegates the display of crashes to apport, which in turn refuses to write the dump because the program is not an installed package. To remedy the problem, we need to make sure apport writes core dump files for non-package programs as well. To do so, create a file named ~/.config/apport/settings with the following contents: [main] unpackaged=true Now crash your program again, and see your crash files being generated within folder: /var/crash with names like *.1000.crash. Note that these files cannot be read by gdb directly. [Optional] To make the dumps readble by gdb, run the following command: apport-unpack <location_of_report> <target_directory>

引用: Core_dump - Oracle VM VirtualBox

随着systemd的启动，还有另一个场景。默认情况下，systemd将在其日志中存储核心转储，可以使用systemd-coredumpctl命令访问。在core_pattern-file中定义:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

检查存储的核心转储的最简单方法是通过coredumpctl列表(旧的核心转储可能已经被自动删除)。 这种行为可以通过简单的“hack”来禁用:

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

与往常一样，核心转储的大小必须等于或高于正在转储的核心的大小，例如使用ulimit -c unlimited。

如果您在RHEL上缺少二进制文件的核心转储，并且在使用abrt时， 确保/etc/abrt/abrt-action-save-package-data.conf

包含

ProcessUnpackaged = yes

这允许为不属于已安装包(例如本地构建的)的二进制文件创建崩溃报告(包括核心转储)。

在最近的Ubuntu(我的例子是12.04)上，可能会打印“分割错误(核心转储)”，但不会在您可能期望的地方生成核心文件(例如本地编译程序)。

如果你的核心文件大小ulimit为0(你没有使用ulimit -c unlimited)就会发生这种情况——这是Ubuntu的默认值。通常情况下，这会抑制“(core dump)”，提示你的错误，但在Ubuntu上，corefiles通过/proc/sys/kernel/core_pattern管道到Apport (Ubuntu的崩溃报告系统)，这似乎导致了误导性的消息。

If Apport discovers that the program in question is not one it should be reporting crashes for (which you can see happening in /var/log/apport.log), it falls back to simulating the default kernel behaviour of putting a core file in the cwd (this is done in the script /usr/share/apport/apport). This includes honouring ulimit, in which case it does nothing. But (I assume) as far as the kernel is concerned, a corefile was generated (and piped to apport), hence the message "Segmentation fault (core dumped)".

最终PEBKAC忘记设置ulimit，但误导性的消息让我认为我疯了一阵子，不知道是什么在吃我的corefiles。

(此外，通常情况下，core(5)手册页——man 5 core——是一个很好的参考，可以了解您的core文件的结束位置以及可能不编写它的原因。)

我可以想到以下两种可能性:

正如其他人已经指出的那样，程序可能会chdir()。是否允许运行程序的用户写入chdir()指定的目录?如果没有，则不能创建核心转储。 出于某种奇怪的原因，内核转储不命名为core。你可以检查/proc/sys/kernel/core_pattern。此外，您命名的find命令不会找到典型的核心转储。你应该使用find / name "*core "。*”，因为coredump的典型名称是core.$PID