【发布时间】：2015-08-01 19:12:59
【问题描述】：
我正在运行自定义 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。
- 生成的核心文件远远超出了此设置的限制。为什么？
- 生成的 4 个核心文件中的 2 个被截断，但正好是
4096字节。这是怎么回事？
我知道核心文件包含分配的完整堆栈和堆内存等内容。对于这样一个简单的程序（最多给或取几个字节），这不应该是相当恒定的，从而在多个实例之间产生一致的核心吗？
编辑：
1du的请求输出
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
【问题讨论】：
-
首先，
du显示核心文件使用的实际字节数是多少？另外，memset()内存。简单地执行malloc()不会导致实际内存被映射到进程中。 -
4096 是虚拟内存页面大小。创建核心转储后，分配给进程的所有 vm 页面都将转储到核心文件中。较小的文件为 2933 页，较大的文件为 2934 页。所以这是相当一致的。
-
@AndrewHenle 添加
memset()确实使事情更加一致，但并非完全一致。我已经用这个和du结果更新了我的问题。 -
@user3386109 是有道理的。但是 gdb 抱怨这两个被截断了，但另外两个完全没问题。因此，对于所有 4 个内核，它都需要
12017664字节。 -
程序变得如此之大，因为它们没有分配物理内存，只是分配虚拟内存。当 GLIBC 的 malloc() 被赋予大量内存来分配它时，请求在内核的另一个虚拟内存页面中执行此操作。出于某种原因，核心文件正在写入所有内存，包括从未物理存在的字节（这很奇怪，因为大多数文件系统的 Linux 中的文件都可以离开file holes）。