在我的 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++ 的舞蹈（也许只是尝试访问“深入其中”） “ 足够的）。收集所有内容并通过您的发行版的错误报告渠道进行报告。