在运行C程序时,它说“(核心转储)”,但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件,但没有得到核心转储文件? 有人帮忙吗,我的核心文件呢?
在运行C程序时,它说“(核心转储)”,但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件,但没有得到核心转储文件? 有人帮忙吗,我的核心文件呢?
当前回答
如果您使用Fedora,为了生成核心转储文件在同一目录下的二进制文件:
echo "core.%e.%p" > /proc/sys/kernel/core_pattern
And
ulimit -c unlimited
其他回答
在最近的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文件的结束位置以及可能不编写它的原因。)
随着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列表(旧的核心转储可能已经被自动删除)。 这种行为可以通过简单的“hack”来禁用:
$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core # or just reboot
与往常一样,核心转储的大小必须等于或高于正在转储的核心的大小,例如使用ulimit -c unlimited。
一行代码获取最新的核心转储路径:
ls -t $(cat /proc/sys/kernel/core_pattern | awk -F% '{print $1"*"}') 2>/dev/null | head -1
当然,您可以将该行的最后一个-1修改为-4,以获得最后4个核心转储。
注意:如果路径模式在最后一个/之前使用变量,或者当非核心转储文件在该目录下时,这并不预期会起作用。
对于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'
我在WSL的努力没有成功。
对于那些运行在Windows子系统For Linux (WSL)上的系统,此时似乎存在一个丢失核心转储文件的公开问题。
这些评论表明
这是我们已经意识到的一个已知问题,也是我们正在调查的事情。
Github的问题
Windows开发者反馈