在运行C程序时，它说“(核心转储)”，但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件，但没有得到核心转储文件? 有人帮忙吗，我的核心文件呢?
当前回答
我在WSL的努力没有成功。
对于那些运行在Windows子系统For Linux (WSL)上的系统，此时似乎存在一个丢失核心转储文件的公开问题。
这些评论表明
这是我们已经意识到的一个已知问题，也是我们正在调查的事情。
Github的问题
Windows开发者反馈
其他回答
我在WSL的努力没有成功。
对于那些运行在Windows子系统For Linux (WSL)上的系统，此时似乎存在一个丢失核心转储文件的公开问题。
这些评论表明
这是我们已经意识到的一个已知问题，也是我们正在调查的事情。
Github的问题
Windows开发者反馈
编写在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
如果您使用Fedora，为了生成核心转储文件在同一目录下的二进制文件:
echo "core.%e.%p" > /proc/sys/kernel/core_pattern
And
ulimit -c unlimited
一行代码获取最新的核心转储路径:
ls -t $(cat /proc/sys/kernel/core_pattern | awk -F% '{print $1"*"}') 2>/dev/null | head -1
当然，您可以将该行的最后一个-1修改为-4，以获得最后4个核心转储。
注意:如果路径模式在最后一个/之前使用变量，或者当非核心转储文件在该目录下时，这并不预期会起作用。
读/usr/src/linux/Documentation / sysctl / kernel.txt。
Core_pattern用于指定核心dumpfile模式名。 如果模式的第一个字符是'|'，内核将进行处理 模式的其余部分作为要运行的命令。核心转储将是 写入该程序的标准输入，而不是写入文件。
您的系统不是将核心转储写入磁盘，而是将其发送到abrt(意思是:自动错误报告工具，而不是“abort”)程序。自动错误报告工具可能没有像它应该被记录的那样…
在任何情况下，快速的答案是您应该能够在/var/cache/abrt中找到您的核心文件，abrt在调用后将它存储在那里。类似地，使用Apport的其他系统可能会在/var/crash中存放内核，等等。
