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

我已经设置并验证了ulimit:

ulimit -c unlimited 
ulimit -a 

我还试图找到一个名为“核心”的文件,但没有得到核心转储文件? 有人帮忙吗,我的核心文件呢?


当前回答

编写在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

其他回答

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

/var/lib/apport/coredump 

在最近的Ubuntu(我的例子是12.04)上,可能会打印“分割错误(核心转储)”,但不会在您可能期望的地方生成核心文件(例如本地编译程序)。

如果你的核心文件大小ulimit为0(你没有使用ulimit -c unlimited)就会发生这种情况——这是Ubuntu的默认值。通常情况下,这会抑制“(core dump)”,提示你的错误,但在Ubuntu上,corefiles通过/proc/sys/kernel/core_pattern管道到Apport (Ubuntu的崩溃报告系统),这似乎导致了误导性的消息。

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

最终PEBKAC忘记设置ulimit,但误导性的消息让我认为我疯了一阵子,不知道是什么在吃我的corefiles。

(此外,通常情况下,core(5)手册页——man 5 core——是一个很好的参考,可以了解您的core文件的结束位置以及可能不编写它的原因。)

我使用的是Linux Mint 19(基于Ubuntu 18)。我想在当前文件夹中有coredump文件。我必须做两件事:

修改/proc/sys/kernel/core_pattern(通过# echo "core.%p.%s.%c.%d. "# sysctl -w kernel.core_pattern=core.% P .%s.%c.%d.%P) 通过$ ulimit -c无限提高核心文件大小的限制

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

编写在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

我在WSL的努力没有成功。

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

这些评论表明

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

Github的问题

Windows开发者反馈