debugging - 为什么核心文件大于虚拟内存？

Question

我有一个多线程程序正在运行，它在一两天后崩溃。此外，核心转储的 gdb 回溯不会导致任何地方。它崩溃的地方没有符号。

现在生成核心文件的机器拥有 3 Gigs 的物理内存和 5 Gigs 交换空间。但是我们得到的核心转储大约是 25 Gigs。核心转储实际上不是内存转储吗？为什么核心转储很大？

谁能给我更多指导如何在这种情况下进行调试？

Answer 1

如果您运行的是 64 位操作系统，那么您可以拥有超过可用物理内存 + 交换空间数倍的文件支持映射。

从内核版本 2.6.23 开始，Linux 提供了一种机制来控制核心转储文件中包含的内容，称为核心转储过滤器。过滤器的值是通过 /proc/<pid>/coredump_filter 操作的位字段。文件(参见 core(5) 手册页):

位 0 (0x01) - 匿名私有(private)映射(例如动态分配的内存)

位 1 ( 0x02 ) - 匿名共享映射

位 2 ( 0x04 ) - 文件支持的私有(private)映射

位 3 ( 0x08 ) - 文件支持的共享映射(例如共享库)

位 4 ( 0x10 ) - ELF header

位 5 ( 0x20 ) - 私有(private)大页面

位 6 ( 0x40 ) - 共享大页

默认值为 0x33这对应于转储所有匿名映射以及 ELF header (但仅当内核使用 CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS 编译时)和私有(private)大页面。从此文件中读取会返回过滤器的十六进制值。将新的十六进制值写入 coredump_filter更改特定过程的过滤器，例如要启用所有可能的映射的转储，可以:

echo 0x7f > /proc/<pid>/coredump_filter

(其中 <pid> 是进程的 PID)

核心转储过滤器的值继承于 fork() 创建的子进程中。 .

某些 Linux 发行版可能会更改 init 的过滤器值。在操作系统启动阶段的早期进程，例如启用转储文件支持的映射。这将影响以后启动的任何进程。