Linux 核心已转储，但核心文件不在当前目录中？

Core dumped, but core file is not in the current directory?

提问by webminal.org

While running a C program, It says "(core dumped)"but I can't see any files under the current path.

在运行 C 程序时，它说“（核心转储）”，但我在当前路径下看不到任何文件。

I have set and verified the ulimit:

我已经设置并验证了ulimit：

ulimit -c unlimited 
ulimit -a 

I also tried to find a file named "core", but didn't get the core dumped file?
Any help, where is my core file?

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

采纳答案by ephemient

Read /usr/src/linux/Documentation/sysctl/kernel.txt.

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

[/proc/sys/kernel/]core_pattern is used to specify a core dumpfile pattern name.

• If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file.

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

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

Instead of writing the core dump to disk, your system is configured to send it to the abrtprogram instead. Automated Bug Reporting Toolis possibly not as documented as it shouldbe...

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

In any case, the quick answer is that you should be able to find your core file in /var/cache/abrt, where abrtstores it after being invoked. Similarly, other systems using Apportmay squirrel away cores in /var/crash, and so on.

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

回答by ahans

I could think of two following possibilities:

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

1. As others have already pointed out, the program might chdir(). Is the user running the program allowed to write into the directory it chdir()'ed to? If not, it cannot create the core dump.

2. For some weird reason the core dump isn't named core.*You can check /proc/sys/kernel/core_patternfor that. Also, the find command you named wouldn't find a typical core dump. You should use find / -name "*core.*", as the typical name of the coredump is core.$PID

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

2. 出于某种奇怪的原因，核心转储没有命名core.*您可以检查/proc/sys/kernel/core_pattern一下。此外，您命名的 find 命令不会找到典型的核心转储。您应该使用find / -name "*core.*"，因为核心转储的典型名称是core.$PID

回答by timss

With the launch of systemd, there's another scenario aswell. By default systemd will store core dumps in its journal, being accessible with the systemd-coredumpctlcommand. Defined in the core_pattern-file:

随着systemd的推出，还有另一种情况。默认情况下，systemd 会将核心转储存储在其日志中，可通过systemd-coredumpctl命令访问。在 core_pattern-file 中定义：

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

This behaviour can be disabled with a simple "hack":

可以通过简单的“hack”禁用此行为：

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

As always, the size of core dumps has to be equal or higher than the size of the core that is being dumped, as done by for example ulimit -c unlimited.

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

回答by jtn

On recent Ubuntu (12.04 in my case), it's possible for "Segmentation fault (core dumped)" to be printed, but no core file produced where you might expect one (for instance for a locally compiled program).

在最近的 Ubuntu（在我的情况下为 12.04）上，可能会打印“Segmentation fault (core dumped)”，但不会在您期望的地方生成核心文件（例如对于本地编译的程序）。

This can happen if you have a core file size ulimit of 0 (you haven't done ulimit -c unlimited) -- this is the default on Ubuntu. Normally that would suppress the "(core dumped)", cluing you into your mistake, but on Ubuntu, corefiles are piped to Apport(Ubuntu's crash reporting system) via /proc/sys/kernel/core_pattern, and this seems to cause the misleading message.

如果您的核心文件大小 ulimit 为 0（您还没有这样做ulimit -c unlimited），就会发生这种情况——这是 Ubuntu 上的默认设置。通常，这会抑制“(core dumped)”，使您陷入错误，但在 Ubuntu 上，核心文件通过管道传送到Apport（Ubuntu 的崩溃报告系统）/proc/sys/kernel/core_pattern，这似乎会导致误导性消息。

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)".

如果 Apport 发现有问题的程序不是它应该报告崩溃的程序（您可以/var/log/apport.log在/usr/share/apport/apport）。这包括遵守 ulimit，在这种情况下它什么都不做。但是（我假设）就内核而言，生成了一个核心文件（并通过管道传输到 apport），因此消息“分段错误（核心转储）”。

Ultimately PEBKAC for forgetting to set ulimit, but the misleading message had me thinking I was going mad for a while, wondering what was eating my corefiles.

最终 PEBKAC 忘记设置 ulimit，但误导性消息让我以为我发疯了一段时间，想知道是什么在吃我的核心文件。

(Also, in general, the core(5) manual page -- man 5 core-- is a good reference for where your core file ends up and reasons it might not be written.)

（此外，一般而言，core(5) 手册页 -- man 5 core-- 是您的核心文件结束位置以及可能不会编写的原因的很好参考。）

回答by MRalwasser

If you're missing core dumps for binaries on RHELand when using abrt, make sure that /etc/abrt/abrt-action-save-package-data.conf

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

contains

包含

ProcessUnpackaged = yes

This enables the creation of crash reports (including core dumps) for binaries which are not part of installed packages(e.g. locally built).

这使得能够为不属于已安装包（例如本地构建）的二进制文件创建崩溃报告（包括核心转储）。

回答by mahaveer darade

For fedora25, I could find core file at

对于 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'

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

回答by ankurrc

Writing instructions to get a core dump under Ubuntu 16.04 LTS:

在Ubuntu 16.04 LTS下编写获取核心转储的说明：

1. 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.

2. To remedy the problem, we need to make sure apportwrites core dump files for non-packageprograms as well. To do so, create a file named ~/.config/apport/settingswith the following contents:
   [main] unpackaged=true

3. Now crash your program again, and see your crash files being generated within folder: /var/crashwith names like *.1000.crash. Note that these files cannot be read by gdbdirectly.

4. [Optional]To make the dumps readble by gdb, run the following command:

   apport-unpack <location_of_report> <target_directory>

1. 正如@jtn 在他的回答中提到的那样，Ubuntu 将崩溃的显示委托给apport，而apport又拒绝写入转储，因为该程序不是已安装的包。

2. 为了解决这个问题，我们需要确保apport 也为非包程序编写核心转储文件。为此，请创建一个名为~/.config/apport/settings 的文件，其中包含以下内容：
   [main] unpackaged=true

3. 现在再次使您的程序崩溃，并看到您的崩溃文件在文件夹中生成：/var/crash，名称类似于*.1000.crash。请注意，这些文件不能被gdb直接读取。

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

   apport-unpack <location_of_report> <target_directory>

References: Core_dump – Oracle VM VirtualBox

参考资料： Core_dump – Oracle VM VirtualBox

回答by Brandon S?ren Culley

My efforts in WSL have been unsuccessful.

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

For those running on Windows Subsystem for Linux (WSL) there seems to be an open issue at this time for missing core dump files.

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

The comments indicate that

评论表明，

This is a known issue that we are aware of, it is something we are investigating.

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

Github issue

Github 问题

Windows Developer Feedback

Windows 开发人员反馈

回答by Nicolas VERHELST

ulimit -c unlimitedmade the core file correctly appear in the current directory after a "core dumped".

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

回答by Nicolas Gong

In Ubuntu18.04, the most easist way to get a core file is inputing the command below to stop the apport service.

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

sudo service apport stop

Then rerun the application, you will get dump file in current directory.

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