我正在运行自定义 2.6.27 内核，我刚刚注意到在段错误期间生成的核心文件大于为进程设置的硬核文件大小限制。

更奇怪的是，核心文件只是有时被截断(但没有达到 ulimit 设置的限制)。

例如，这是我将在下面尝试并崩溃的程序:

int main(int argc, char **argv)
{
    // Get the hard and soft limit from command line
    struct rlimit new = {atoi(argv[1]), atoi(argv[1])};

    // Create some memory so as to beef up the core file size
    void *p = malloc(10 * 1024 * 1024);

    if (!p)
        return 1;

    if (setrlimit(RLIMIT_CORE, &new)) // Set the hard and soft limit
        return 2;                     // for core files produced by this
                                      // process

    while (1);

    free(p);
    return 0;
}

这是执行:

Linux# ./a.out 1446462 &    ## Set hard and soft limit to ~1.4 MB
[1] 14802
Linux# ./a.out 1446462 &
[2] 14803
Linux# ./a.out 1446462 &
[3] 14804
Linux# ./a.out 1446462 &
[4] 14807

Linux# cat /proc/14802/limits | grep core
Max core file size        1446462              1446462              bytes

Linux# killall -QUIT a.out

Linux# ls -l
total 15708
-rwxr-xr-x 1 root root     4624 Aug  1 18:28 a.out
-rw------- 1 root root 12013568 Aug  1 18:39 core.14802         <=== truncated core
-rw------- 1 root root 12017664 Aug  1 18:39 core.14803
-rw------- 1 root root 12013568 Aug  1 18:39 core.14804         <=== truncated core
-rw------- 1 root root 12017664 Aug  1 18:39 core.14807
[1]   Quit                    (core dumped) ./a.out 1446462
[2]   Quit                    (core dumped) ./a.out 1446462
[3]   Quit                    (core dumped) ./a.out 1446462
[4]   Quit                    (core dumped) ./a.out 1446462

所以这里发生了很多事情。我将每个进程的硬限制设置为大约 1.4 MB。

1. 生成的核心文件远远超过了这个设定的限制。为什么？
2. 生成的 4 个核心文件中有 2 个被截断了，但恰好截断了 4096 字节。这是怎么回事？

我知道核心文件包含已分配的完整堆栈和堆内存等内容。对于这样一个简单的程序(最多提供或使用几个字节)，这不应该是几乎恒定的，从而在多个实例之间产生一致的核心吗？

编辑:

1 du

Linux# du core.*
1428    core.14802
1428    core.14803
1428    core.14804
1428    core.14807

Linux# du -b core.*
12013568    core.14802
12017664    core.14803
12013568    core.14804
12017664    core.14807

2 在 malloc() 之后添加 memset() 绝对控制了一切，因为核心文件现在都被截断为 1449984(仍然超过限制 3522 字节)。

那么之前的地核为什么那么大，里面装的是什么？不管是什么，它都不受过程限制。

3 新程序也显示了一些有趣的行为:

Linux# ./a.out 12017664 &
[1] 26586
Linux# ./a.out 12017664 &
[2] 26589
Linux# ./a.out 12017664 &
[3] 26590
Linux# ./a.out 12017663 &        ## 1 byte smaller
[4] 26653
Linux# ./a.out 12017663 &        ## 1 byte smaller
[5] 26666
Linux# ./a.out 12017663 &        ## 1 byte smaller
[6] 26667

Linux# killall -QUIT a.out

Linux# ls -l
total ..
-rwxr-xr-x 1 root root     4742 Aug  1 19:47 a.out
-rw------- 1 root root 12017664 Aug  1 19:47 core.26586
-rw------- 1 root root 12017664 Aug  1 19:47 core.26589
-rw------- 1 root root 12017664 Aug  1 19:47 core.26590
-rw------- 1 root root  1994752 Aug  1 19:47 core.26653           <== ???
-rw------- 1 root root  9875456 Aug  1 19:47 core.26666           <== ???
-rw------- 1 root root  9707520 Aug  1 19:47 core.26667           <== ???
[1]   Quit                    (core dumped) ./a.out 12017664
[2]   Quit                    (core dumped) ./a.out 12017664
[3]   Quit                    (core dumped) ./a.out 12017664
[4]   Quit                    (core dumped) ./a.out 12017663
[5]   Quit                    (core dumped) ./a.out 12017663
[6]   Quit                    (core dumped) ./a.out 12017663

最佳答案

核心转储的实现可以在fs/binfmt_elf.c中找到。我将遵循 3.12 及更高版本中的代码(它更改为 commit 9b56d5438 )但逻辑非常相似。

代码最初决定在 vma_dump_size 中转储多少 VMA(虚拟内存区域)。对于匿名 VMA，例如 brk 堆，它返回 VMA 的完整大小。此步骤不涉及核心限制。

编写核心转储的第一阶段然后为每个 VMA 编写一个 PT_LOAD header 。这基本上是一个指针，指示在 ELF 文件的其余部分中的何处查找数据。实际数据由for循环写入，实际上是第二阶段。

在第二阶段，elf_core_dump 反复调用get_dump_page 为程序地址空间的每一页获取一个struct page 指针被倾倒。 get_dump_page 是 mm/gup.c 中的一个常见实用函数。 get_dump_page 的注释很有帮助:

 * Returns NULL on any kind of failure - a hole must then be inserted into
 * the corefile, to preserve alignment with its headers; and also returns
 * NULL wherever the ZERO_PAGE, or an anonymous pte_none, has been found -
 * allowing a hole to be left in the corefile to save diskspace.

事实上 elf_core_dump 调用了 fs/coredump.c 中的一个函数(内核中的 dump_seek，dump_skip 在 3.12+ 中)如果 get_dump_page 返回 NULL。此函数调用 lseek 以在转储中留下一个空洞(实际上，因为这是内核，它直接在 struct file 指针上调用 file->f_op->llseek)。 主要区别在于 dump_seek 确实不遵守 ulimit，而较新的 dump_skip 则遵守。

至于为什么第二个程序有奇怪的行为，可能是因为ASLR(地址空间随机化)。截断哪个 VMA 取决于 VMA 的相对顺序，这是随机的。你可以尝试禁用它

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

看看你的结果是否更均匀。要重新启用 ASLR，请使用

echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

关于核心文件大小限制对进程具有不确定性影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31765282/