如何在使用 GDB 生成进程核心文件之前预测其大小？

Question

如何根据例如

/proc/pid/maps

、

/proc/pid/coredump_filter

、

top

显示的值（如

VIRT RES

等）来预测核心文件的大小？

一般来说，核心文件的大小取决于什么以及文件到底包含什么（虚拟地址空间的哪些部分？）？

我对核心文件可能小于

VIRT

或

/proc/pid/maps

中所有内存范围的总和这一事实感到有点困惑，所以我怀疑该文件不完整。

Answer 1

如何根据 /proc/pid/maps、/proc/pid/coredump_filter、顶部显示的值（如 VIRT RES 等）来预测核心文件的大小？

上限是

/proc/$$/maps

中所有映射的总和。但是，通常只读映射不会保存在

core

中（假设您在使用

core

时映射的只读文件可用）。

下界是

/proc/$$/maps

中所有可写映射的总和。这是一个下限，因为内核通常还会转储可执行只读映射的第一页，因为那是链接器

BUILD_ID

ELF note 所在的位置。该注释允许 GDB 找到所使用的可执行文件或共享库的正确版本，即使系统已更新为较新的版本。

core

还包含每个线程的寄存器转储。 ELF 格式本身也有一些开销。

VIRT 和 RES 通常不是一个好的估计：VIRT “太大”——它包含只读映射，以及被

mmap

编入进程但实际上尚未分页的页面。RES如果您的部分内存已被换出，则可能太小。

我对核心文件可能小于 VIRT 或 /proc/pid/maps 中所有内存范围的总和这一事实感到有点困惑，所以我怀疑该文件不完整。

正如我上面所解释的，

core

小于

VIRT

以及

/proc/pid/maps

中所有内存范围的总和是正常且符合预期的。

最后，如果您确实希望在实际转储核心之前找到相当精确的估计，您可能希望研究 Google user-space coredumper。