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

Ulimit -c unlimited使内核文件在“内核转储”后正确地出现在当前目录中。

在我的例子中，原因是ulimit命令只影响当前终端。

如果我在第一个终端上设置ulimit -c unlimited。然后我启动一个新的终端来运行程序。当内核转储时，它不会生成内核文件。

您必须确认运行您的程序的终端的核心大小。

以下步骤适用于ubuntu 20.04和ubuntu 21.04:

停止分配服务

sudo service apport stop

设置准备运行程序的终端的核心大小

ulimit -c unlimited

在Ubuntu18.04中，获取核心文件最简单的方法是输入下面的命令来停止apport服务。

sudo service apport stop

然后重新运行应用程序，你将得到转储文件在当前目录。

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

包含

ProcessUnpackaged = yes

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

在最近的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文件的结束位置以及可能不编写它的原因。)