在运行C程序时，它说“(核心转储)”，但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件，但没有得到核心转储文件? 有人帮忙吗，我的核心文件呢?
当前回答
我可以想到以下两种可能性:
正如其他人已经指出的那样，程序可能会chdir()。是否允许运行程序的用户写入chdir()指定的目录?如果没有，则不能创建核心转储。 出于某种奇怪的原因，内核转储不命名为core。你可以检查/proc/sys/kernel/core_pattern。此外，您命名的find命令不会找到典型的核心转储。你应该使用find / name "*core "。*”，因为coredump的典型名称是core.$PID
其他回答
我在这里找到了Ubuntu 20.04系统的核心文件;
/var/lib/apport/coredump
随着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。
在Ubuntu18.04中，获取核心文件最简单的方法是输入下面的命令来停止apport服务。
sudo service apport stop
然后重新运行应用程序，你将得到转储文件在当前目录。
一行代码获取最新的核心转储路径:
ls -t $(cat /proc/sys/kernel/core_pattern | awk -F% '{print $1"*"}') 2>/dev/null | head -1
当然，您可以将该行的最后一个-1修改为-4，以获得最后4个核心转储。
注意:如果路径模式在最后一个/之前使用变量，或者当非核心转储文件在该目录下时，这并不预期会起作用。
对于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'
