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

Question

如何根据 /proc/pid/maps 预测核心文件的大小？ , /proc/pid/coredump_filter , 值显示为 top喜欢VIRT RES等等？

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

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

Answer 1

How can the size of the core file be predicted based on for example /proc/pid/maps, /proc/pid/coredump_filter, values shown by top like VIRT RES and so on?

上限是/proc/$$/maps 中所有映射的总和。但是，通常只读映射不会保存在核心中(假设您在使用核心).

下界是/proc/$$/maps 中所有可写映射的总和。这是一个下限，因为内核通常还会转储可执行只读映射的第一页，因为那是链接器 BUILD_ID ELF 注释所在的位置。该注释允许 GDB 找到所使用的可执行文件或共享库的正确版本，即使系统已更新为较新版本。 core 还包含每个线程的寄存器转储。 ELF 格式本身也有一些开销。

VIRT 和 RES 通常不是一个好的估计:VIRT “太大”——它包含只读映射，以及被 mmap 编入进程但还没有的页面实际上并没有被调入。如果您的部分内存已被换出，RES 可能太小。

I'm a little confused by a fact that the core file may be smaller than a VIRT or a sum of all memory ranges in /proc/pid/maps, so I suspect the file to be incomplete.

正如我上面所解释的，core 小于 VIRT 并且 /proc/pid/maps 中所有内存范围的总和是正常和预期。

最后，如果你真的希望在实际转核之前找到一个相当精确的估计，不妨谷歌一下user-space coredumper .