在运行C程序时，它说“(核心转储)”，但我看不到当前路径下的任何文件。
我已经设置并验证了ulimit:
ulimit -c unlimited
ulimit -a
我还试图找到一个名为“核心”的文件，但没有得到核心转储文件? 有人帮忙吗，我的核心文件呢?
当前回答
Ulimit -c unlimited使内核文件在“内核转储”后正确地出现在当前目录中。
其他回答
如果您使用Fedora，为了生成核心转储文件在同一目录下的二进制文件:
echo "core.%e.%p" > /proc/sys/kernel/core_pattern
And
ulimit -c unlimited
在我的例子中，原因是ulimit命令只影响当前终端。
如果我在第一个终端上设置ulimit -c unlimited。然后我启动一个新的终端来运行程序。当内核转储时，它不会生成内核文件。
您必须确认运行您的程序的终端的核心大小。
以下步骤适用于ubuntu 20.04和ubuntu 21.04:
停止分配服务
sudo service apport stop
设置准备运行程序的终端的核心大小
ulimit -c unlimited
我在WSL的努力没有成功。
对于那些运行在Windows子系统For Linux (WSL)上的系统，此时似乎存在一个丢失核心转储文件的公开问题。
这些评论表明
这是我们已经意识到的一个已知问题，也是我们正在调查的事情。
Github的问题
Windows开发者反馈
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文件的结束位置以及可能不编写它的原因。)
