核心转储,但核心文件不在当前目录中？

Question

在运行C程序时,它说"(core dumped)"但我看不到当前路径下的任何文件.

我已经设置并验证了ulimit:

ulimit -c unlimited 
ulimit -a 

我还试图找到一个名为"core"的文件,但没有得到核心转储文件？
任何帮助,我的核心文件在哪里？

Answer 1

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

[/ proc/sys/kernel /] core_pattern用于指定核心转储文件模式名称.

• 如果模式的第一个字符是"|",则内核会将模式的其余部分视为要运行的命令.核心转储将写入该程序的标准输入而不是文件.

您的系统不是将核心转储写入磁盘,abrt而是将其配置为将其发送到程序. 自动错误报告工具可能没有应有的记录 ......

在任何情况下,快速回答是您应该能够找到您的核心文件/var/cache/abrt,在abrt调用后存储它.类似地,使用Apport的其他系统可能会将核心松开/var/crash,等等.

Answer 2

在最近的Ubuntu(在我的情况下为12.04)中,可能会打印"Segmentation fault(core dumped)",但是没有生成核心文件(例如本地编译的程序).

如果你的核心文件大小为ulimit为0(你还没有ulimit -c unlimited),就会发生这种情况 - 这是Ubuntu的默认设置.通常这会抑制"(核心转储)",让你陷入错误,但在Ubuntu上,核心文件通过管道输送到Apport(Ubuntu的崩溃报告系统)/proc/sys/kernel/core_pattern,这似乎会引起误导性的消息.

如果Apport发现有问题的程序不是一个,它应该报告崩溃(你可以看到发生/var/log/apport.log),它回退到模拟将核心文件放入cwd的默认内核行为(这是在脚本中完成的)/usr/share/apport/apport).这包括尊重ulimit,在这种情况下它什么都不做.但是(我假设)就内核而言,生成了一个核心文件(并通过管道传输给apport),因此消息"Segmentation fault(core dumped)".

最终PEBKAC忘了设置ulimit,但误导性的消息让我觉得我已经疯了一会儿,想知道吃了我的核心文件是什么.

(另外,一般来说,核心(5)手册页 - man 5 core- 是核心文件最终结束的原因以及可能无法编写的原因.)

Answer 3

随着systemd的推出,还有另一个场景.默认情况下,systemd会将核心转储存储在其日志中,可通过该systemd-coredumpctl命令访问.在core_pattern文件中定义:

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

可以使用简单的"hack"禁用此行为:

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

与往常一样,核心转储的大小必须等于或高于正在转储的核心的大小,例如,如同所做的那样ulimit -c unlimited.

Answer 4

编写指令以在Ubuntu 16.04 LTS下获取核心转储:

1. 正如@jtn在他的回答中提到的,Ubuntu将崩溃的显示委托给apport,后者反过来拒绝编写转储,因为该程序不是已安装的软件包.

2. 为了解决这个问题,我们需要确保apport也为非程序包程序编写核心转储文件.为此,请使用以下内容创建名为〜/ .config/apport/settings的文件:
   [main] unpackaged=true

3. 现在再次崩溃程序,并在文件夹:/ var/crash中看到生成的崩溃文件,其名称如*.1000.crash.请注意,gdb无法直接读取这些文件.

4. [可选]要使转储由gdb读取,请运行以下命令:

   apport-unpack <location_of_report> <target_directory>

参考: Core_dump - Oracle VM VirtualBox

Answer 5

我在以下位置找到了 Ubuntu 20.04 系统的核心文件：

/var/lib/apport/coredump 

Answer 6

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

1. 正如其他人已经指出的那样,该计划可能会chdir().运行程序的用户是否允许写入它所chdir()要的目录？如果没有,则无法创建核心转储.

2. 出于某些奇怪的原因,核心转储未命名core.*您可以检查/proc/sys/kernel/core_pattern它.此外,您命名的find命令找不到典型的核心转储.您应该使用find / -name "*core.*",作为coredump的典型名称core.$PID

Answer 7

如果你缺少的核心转储上的二进制RHEL和使用时abrt,请确保/etc/abrt/abrt-action-save-package-data.conf

包含

ProcessUnpackaged = yes

这样就可以为不属于已安装软件包(例如本地构建)的二进制文件创建崩溃报告(包括核心转储).

Answer 8

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

sudo service apport stop

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

Answer 9

我使用的是 Linux Mint 19（基于 Ubuntu 18）。我想coredump在当前文件夹中包含文件。我必须做两件事：

1. 改变/proc/sys/kernel/core_pattern（通过# echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern或通过# sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
2. 将核心文件大小限制提高$ ulimit -c unlimited

这已经写在答案中了，但我写的只是为了简洁地总结一下。有趣的是，更改限制不需要 root 权限（根据https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root 只能降低限制，所以这是意想不到的 - 欢迎对此发表评论）。

Answer 10

对于 fedora25，我可以在以下位置找到核心文件

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

其中ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %根据`/proc/sys/kernel/core_pattern'

Answer 11

就我而言，原因是 ulimit 命令仅影响当前终端。

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

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

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

1. 停止申请服务

sudo service apport stop

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

ulimit -c unlimited

Answer 12

我在 WSL 上的努力没有成功。

对于那些在 Linux 的 Windows 子系统 (WSL) 上运行的用户，目前似乎存在缺少核心转储文件的未解决问题。

评论表明，

这是我们知道的一个已知问题，这是我们正在调查的问题。

Github 问题

Windows 开发人员反馈