我正在运行自定义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。
4096字节。这里发生了什么？我知道核心文件包含分配的完整堆栈和堆内存等。对于这样一个简单的程序（最多给出或占用几个字节），这不应该是非常恒定的，因此在多个实例之间产生一致的核心吗？
EDITS：
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在memset()之后添加malloc()绝对统治了内容，因为核心文件现在都被截断为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标头。这基本上是一个指针，指示在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（你内核中的get_dump_page，3.12 +中的NULL）中的函数。这个函数调用lseek在转储中留下一个洞（实际上因为这是它直接在file->f_op->llseek指针上调用struct file的内核）。主要的区别是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