我在WSL的努力没有成功。

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

这些评论表明

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

Github的问题

Windows开发者反馈

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

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

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

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

包含

ProcessUnpackaged = yes

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

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

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

And

ulimit -c unlimited