分段错误（核心转储） - 到哪里？它是什么？为什么？

Question

当 Linux 出现段错误时，Segmentation fault (core dumped)会在终端（如果有）打印错误信息，并终止程序。作为 C/C++ 开发人员，这种情况经常发生在我身上，我通常会忽略它并转到gdb，重新创建我之前的操作以再次触发无效的内存引用。相反，我想我也许可以改用这个“核心”，因为一直运行gdb是相当乏味的，而且我不能总是重新创建分段错误。

我的问题是三个：

• 这个难以捉摸的“核心”在哪里倾倒？
• 它包含什么？
• 我可以用它做什么？

Answer 1

如果其他人清理...

......你通常找不到任何东西。但幸运的是 Linux 有一个处理程序，您可以在运行时指定它。在/usr/src/linux/Documentation/sysctl/kernel.txt你会发现：

core_pattern 用于指定核心转储文件模式名称。

• 如果模式的第一个字符是“|”，内核会将模式的其余部分视为要运行的命令。核心转储将写入该程序的标准输入而不是文件。

（参见核心转储，但核心文件不在当前目录中？在 StackOverflow 上）

根据消息来源，这是由abrt程序处理的（即自动错误报告工具，而不是中止），但在我的 Arch Linux 上，它由 systemd 处理。您可能想要编写自己的处理程序或使用当前目录。

但是里面有什么？

现在它包含的内容是特定于系统的，但根据无所不知的百科全书：

[核心转储]由计算机程序工作内存在特定时间的记录状态组成[...]。实际上，其他关键的程序状态通常会同时转储，包括处理器寄存器，其中可能包括程序计数器和堆栈指针、内存管理信息以及其他处理器和操作系统标志和信息。

...所以它基本上包含了所有gdb想要的东西，甚至更多。

是的，但我希望我快乐而不是 gdb

gdb只要您拥有可执行文件的精确副本，您就会感到高兴，因为它会加载任何核心转储：gdb path/to/binary my/core.dump. 然后，您应该能够像往常一样继续业务，并因尝试修复错误但未能修复错误而不是尝试并未能重现错误而感到恼火。

Answer 2

此外，如果ulimit -c返回0，则不会写入核心转储文件。

请参阅在哪里搜索 Linux 应用程序崩溃生成的核心文件？

您还可以手动触发核心转储CTRL-\这会退出进程并导致核心转储。

Answer 3

核心文件通常被调用core，位于进程的当前工作目录中。然而，有很多原因导致核心文件无法生成，并且它可能完全位于其他位置，并且名称不同。有关详细信息，请参阅core.5 手册页：

\n\n

\n

描述

\n\n

某些信号的默认操作是导致进程终止并生成核心转储文件，这是一个包含终止时进程内存映像的磁盘文件。该映像可在调试器（例如 gdb(1)）中使用，以检查程序终止时的状态。 导致进程转储核心的信号列表可以在 signal(7) 中找到。

\n\n

...

\n\n

不生成核心转储文件的情况有多种：

\n\n

   *  The process does not have permission to write the core file.  (By\n      default, the core file is called core or core.pid, where pid is\n      the ID of the process that dumped core, and is created in the\n      current working directory.  See below for details on naming.) \n      Writing the core file will fail if the directory in which it is to\n      be created is nonwritable, or if a file with the same name exists\n      and is not writable or is not a regular file (e.g., it is a\n      directory or a symbolic link).\n   *  A (writable, regular) file with the same name as would be used for\n      the core dump already exists, but there is more than one hard link\n      to that file.\n   *  The filesystem where the core dump file would be created is full;\n      or has run out of inodes; or is mounted read-only; or the user has\n      reached their quota for the filesystem.\n   *  The directory in which the core dump file is to be created does\n      not exist.\n   *  The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)\n      resource limits for the process are set to zero; see getrlimit(2)\n      and the documentation of the shell\'s ulimit command (limit in\n      csh(1)).\n   *  The binary being executed by the process does not have read\n      permission enabled.\n   *  The process is executing a set-user-ID (set-group-ID) program that\n      is owned by a user (group) other than the real user (group) ID of\n      the process, or the process is executing a program that has file\n      capabilities (see capabilities(7)).  (However, see the description\n      of the prctl(2) PR_SET_DUMPABLE operation, and the description of\n      the /proc/sys/fs/suid_dumpable file in proc(5).)\n   *  (Since Linux 3.7) The kernel was configured without the\n      CONFIG_COREDUMP option.\n

\n\n

此外，如果使用 madvise(2) MADV_DONTDUMP 标志，则核心转储可能会排除进程的部分地址空间。

\n\n

核心转储文件的命名

\n\n

默认情况下，核心转储文件名为 core，但可以设置 /proc/sys/kernel/core_pattern 文件（自 Linux 2.6 和 2.4.21 起）来定义用于命名核心转储文件的模板.\n 模板可以包含 % 说明符，在创建核心文件时，这些说明符将被以下值替换：

\n\n

       %%  a single % character\n       %c  core file size soft resource limit of crashing process (since\n           Linux 2.6.24)\n       %d  dump mode\xe2\x80\x94same as value returned by prctl(2) PR_GET_DUMPABLE\n           (since Linux 3.7)\n       %e  executable filename (without path prefix)\n       %E  pathname of executable, with slashes (\'/\') replaced by\n           exclamation marks (\'!\') (since Linux 3.0).\n       %g  (numeric) real GID of dumped process\n       %h  hostname (same as nodename returned by uname(2))\n       %i  TID of thread that triggered core dump, as seen in the PID\n           namespace in which the thread resides (since Linux 3.18)\n       %I  TID of thread that triggered core dump, as seen in the\n           initial PID namespace (since Linux 3.18)\n       %p  PID of dumped process, as seen in the PID namespace in which\n           the process resides\n       %P  PID of dumped process, as seen in the initial PID namespace\n           (since Linux 3.12)\n       %s  number of signal causing dump\n       %t  time of dump, expressed as seconds since the Epoch,\n           1970-01-01 00:00:00 +0000 (UTC)\n       %u  (numeric) real UID of dumped process\n

\n

\n