调试 – 为什么核心文件不仅仅是虚拟内存？

发布时间：2020-12-13 23:06:23 所属栏目：Linux 来源：网络整理

导读：我有一个多线程程序运行,在一两天后崩溃.此外,核心转储的gdb回溯不会导致任何问题.它崩溃的地方没有符号. 现在,生成核心文件的机器具有3 Gigs和5 Gigs交换空间的物理内存.但我们获得的核心转储大约是25 Gigs.难道核心转储实际上是内存转储吗？为什么核心转储

我有一个多线程程序运行,在一两天后崩溃.此外,核心转储的gdb回溯不会导致任何问题.它崩溃的地方没有符号.

现在,生成核心文件的机器具有3 Gigs和5 Gigs交换空间的物理内存.但我们获得的核心转储大约是25 Gigs.难道核心转储实际上是内存转储吗？为什么核心转储量大？

在这种情况下,谁能给我更多关于如何调试的主角？

解决方法

如果您运行的是64位操作系统,则可以使文件支持的映射超过可用物理内存交换空间的数倍.

从内核版本2.6.23开始,Linux提供了一种机制来控制核心转储文件中包含的内容,称为核心转储过滤器.过滤器的值是通过/ proc /< pid> / coredump_filter文件操作的位字段(请参阅core(5)手册页)：

> bit 0(0x01) – 匿名私有映射(例如动态分配的内存)
> bit 1(0x02) – 匿名共享映射
> bit 2(0x04) – 文件支持的私有映射
> bit 3(0x08) – 文件支持的共享映射(例如共享库)
> bit 4(0x10) – ELF头
>第5位(0x20) – 私人大页面
>第6位(0x40) – 共享大页面

默认值为0x33,对应于转储所有匿名映射以及ELF头(但仅当内核使用CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS编译时)和私有大页面.从此文件读取将返回过滤器的十六进制值.将新的十六进制值写入coredump_filter会更改特定进程的过滤器,例如要启用所有可能映射的转储,可以：

echo 0x7f > /proc/<pid>/coredump_filter

(其中< pid>是进程的PID)

核心转储过滤器的值在fork()创建的子进程中是不可靠的.

某些Linux发行版可能会在OS引导阶段的早期更改init进程的过滤器值,例如：启用转储文件支持的映射.这将影响以后开始的任何流程.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!