核心已转储，但核心文件不在当前目录?

在运行C程序时，它说“(信息转储)”，但我看不到当前路径下的任何文件。

我已经设置并验证了ulimit:

ulimit -c unlimited
ulimit -a

我也试图找到一个名为“核心”的文件，但没有得到核心转储文件?< br > 有人帮忙吗，我的核心文件呢?< / p >

449831 次浏览
小开

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

  1. 正如其他人已经指出的，程序可能chdir()。是否允许运行程序的用户写入它__abc0 '所在的目录?如果没有，则不能创建核心转储。

  2. 出于某种奇怪的原因，核心转储没有命名为core.*。此外，您命名的find命令不会找到典型的核心转储。你应该使用find / -name "*core.*"，因为coredump的典型名称是core.$PID

小开
最佳答案

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

Core_pattern用于指定核心dumpfile模式名。

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

而不是将核心转储写入磁盘，您的系统被配置为将其发送到abrt(意思是:自动错误报告工具，不 "abort")程序。自动错误报告工具可能不像它应该 be…

在任何情况下，快速的答案是你应该能够在/var/cache/abrt中找到你的核心文件，在调用后abrt将它存储在那里。类似地，使用幻想的其他系统可能会将内核储存在/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 list(旧的核心转储可能已经被自动删除)。 这种行为可以通过简单的“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 dumps)”，提示你的错误，但在Ubuntu上，corefiles通过/proc/sys/kernel/core_pattern传输到幻想 (Ubuntu的崩溃报告系统)，这似乎会导致误导性的信息。

如果Apport发现有问题的程序不是一个它应该报告崩溃的程序(你可以在/var/log/apport.log中看到发生的情况)，它会返回到模拟将核心文件放入cwd的默认内核行为(这在脚本/usr/share/apport/apport中完成)。这包括尊重ulimit，在这种情况下，它没有任何作用。但是(我假设)就内核而言，生成了一个corefile(并通过管道连接到apport)，因此出现了“分段错误(内核转储)”消息。

最终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下的核心转储:

  1. 正如@jtn在他的回答中提到的，Ubuntu将崩溃的显示委托给apport，它反过来拒绝写入转储，因为该程序不是已安装的包。Before making changes

    2. 为了解决这个问题，我们需要确保幻想也为non-package程序写入核心转储文件。为此，创建一个名为< em > ~ < / em > / config /幻想/设置的文件，包含以下内容:
    <代码>[主要] 散装的= true < /代码> < / p > < /李>
  2. 现在再次让你的程序崩溃，并看到你的崩溃文件在文件夹:/var/crash中生成，名称类似* .1000.crash。注意，这些文件不能被广东发展银行直接读取。After making changes

  3. (可选)要使gdb可读转储文件，执行以下命令:

    apport-unpack <location_of_report> <target_directory> < / p >

< p >引用: Core_dump - Oracle VM VirtualBox < / p >
小开

我在WSL的努力没有成功。

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

这些评论表明

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

Github issue

Windows开发者反馈 .

小开

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

小开

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

sudo service apport stop

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

小开

我使用的是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提高核心文件大小的限制

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

小开

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

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

和

ulimit -c unlimited
小开

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

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

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

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

  1. 停止分配服务
sudo service apport stop
  1. 设置准备运行程序的终端的核心大小
ulimit -c unlimited
小开

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

/var/lib/apport/coredump

提交答案