![C++ 应用程序。用 mmap 杀死内核? (mmap 导致内核恐慌)](https://linux22.com/image/83668/C%2B%2B%20%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E3%80%82%E7%94%A8%20mmap%20%E6%9D%80%E6%AD%BB%E5%86%85%E6%A0%B8%EF%BC%9F%20%EF%BC%88mmap%20%E5%AF%BC%E8%87%B4%E5%86%85%E6%A0%B8%E6%81%90%E6%85%8C%EF%BC%89.png)
在我的 C++ 程序中,发生密集型磁盘、网络 I/O 甚至 CPU 计算,我使用内存映射区域作为数组。
对于非常小的数据,它工作得很好。然而,当我运行带有大量数据的程序时,我的应用程序崩溃了。 (我绝对理解 mmap 区域的大小不应该成为问题,因为操作系统将处理所有 I/O 和缓冲)
我不想将其归咎于Linux,但我想知道是否有任何情况下'mmap'变得不稳定并可能导致操作系统崩溃?
当操作系统崩溃时,在屏幕中我可以看到与一些诸如此类的“write_back”相关的内核恐慌消息...(一旦重现问题,我将在此处添加消息)
// 该程序在内存映射区域(启用了 Infiniband 的 RDMA 的英特尔 MPI)上使用 MPI 网络操作,其中 RDMA 可能绕过操作系统内核并直接将一些数据写入内存。
我调查了调用堆栈并发现了一些内核代码:(http://lxr.free-electrons.com/source/fs/ext4/inode.c#L2313)
我猜这些错误来自 #L2386 BUG_ON(PageWriteback(page)); 中的“BUG_ON”陷阱;内核版本是 3.19.0 (https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.tar.xz)
答案1
你不能原因由于任何系统调用的不当使用而导致的内核恐慌,mmap
包括。系统调用接口不向调用者提供破坏内核数据结构的资金。
我会寻找硬件问题,并仔细注意系统日志中的任何线索,例如/var/log/kernel.log
。作为实验,我尝试将相同大小的文件映射到不同的文件系统上,因为磁盘是最有可能发生故障的组件。
它是可能的你已经惹恼了一个内核错误。快速搜索回写和恐慌出现了[这个老bug]。1 如果您运行的是非常旧的内核,那么当然,可能是时候升级了。
答案2
根据cooments中的描述,他的情况是内核崩溃(panic)。绝对应该绝不发生。
这是什么分布?什么内核版本?建筑学?
首先更新一切。如果您的发行版已停产,请升级。然后再试一次。
如果它持续存在,您应该能够使用一个小型 C 程序来重现这一点,该程序可以mmap()
像您的 C++ 程序一样完成巨大的工作,并在该内存上重复类似于 C++ 的舞蹈(也许只是尝试访问“深入其中”) “ 足够的)。收集所有内容并通过您的发行版的错误报告渠道进行报告。