我有一个多线程程序运行,在一两天后崩溃.此外,核心转储的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进程的过滤器值,例如：启用转储文件支持的映射.这将影响以后开始的任何流程.
相关文章
转载注明原文：调试 – 为什么核心文件不仅仅是虚拟内存？ - 代码日志