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

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

读/usr/src/linux/Documentation / sysctl / kernel.txt。

Core_pattern用于指定核心dumpfile模式名。 如果模式的第一个字符是'|'，内核将进行处理 模式的其余部分作为要运行的命令。核心转储将是 写入该程序的标准输入，而不是写入文件。

您的系统不是将核心转储写入磁盘，而是将其发送到abrt(意思是:自动错误报告工具，而不是“abort”)程序。自动错误报告工具可能没有像它应该被记录的那样…

在任何情况下，快速的答案是您应该能够在/var/cache/abrt中找到您的核心文件，abrt在调用后将它存储在那里。类似地，使用Apport的其他系统可能会在/var/crash中存放内核，等等。

随着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。

在最近的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文件的结束位置以及可能不编写它的原因。)

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

包含

ProcessUnpackaged = yes

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

对于fedora25，我可以在

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

where ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %p % as per ' /proc/sys/kernel/core_pattern'

编写在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

我在WSL的努力没有成功。

对于那些运行在Windows子系统For Linux (WSL)上的系统，此时似乎存在一个丢失核心转储文件的公开问题。

这些评论表明

这是我们已经意识到的一个已知问题，也是我们正在调查的事情。

Github的问题

Windows开发者反馈

Ulimit -c unlimited使内核文件在“内核转储”后正确地出现在当前目录中。

在Ubuntu18.04中，获取核心文件最简单的方法是输入下面的命令来停止apport服务。

sudo service apport stop

然后重新运行应用程序，你将得到转储文件在当前目录。

我使用的是Linux Mint 19(基于Ubuntu 18)。我想在当前文件夹中有coredump文件。我必须做两件事:

修改/proc/sys/kernel/core_pattern(通过# echo "core.%p.%s.%c.%d. "# sysctl -w kernel.core_pattern=core.% P .%s.%c.%d.%P) 通过$ ulimit -c无限提高核心文件大小的限制

这已经写在答案里了，但我写出来是为了简洁地总结。有趣的是，修改限制不需要root权限(根据https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user，非root只能降低限制，所以这是出乎意料的-欢迎评论)。

如果您使用Fedora，为了生成核心转储文件在同一目录下的二进制文件:

echo "core.%e.%p" > /proc/sys/kernel/core_pattern

And

ulimit -c unlimited

在我的例子中，原因是ulimit命令只影响当前终端。

如果我在第一个终端上设置ulimit -c unlimited。然后我启动一个新的终端来运行程序。当内核转储时，它不会生成内核文件。

您必须确认运行您的程序的终端的核心大小。

以下步骤适用于ubuntu 20.04和ubuntu 21.04:

停止分配服务

sudo service apport stop

设置准备运行程序的终端的核心大小

ulimit -c unlimited

我在这里找到了Ubuntu 20.04系统的核心文件;

/var/lib/apport/coredump 

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

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

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

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