Linux：mmap 函数中的随机内核 oop

Question

由于你已经运行记忆测试经过足够长的时间，最明显的硬件嫌疑人已被排除。我认为你已经注意到

 BUG: unable to handle kernel paging request at 0000020000000018

每次都携带相同或不同的地址，对吗？

我无法帮助您完成这份报告，但我建议您使用阿波特收集有关您的崩溃的信息？阿波特是 Ubuntu 官方的崩溃和错误数据收集软件包，你会发现一个这里有很好的介绍。

您需要激活它，（编辑为 sudo /etc/apport/crashdb.conf，找到此行，

  'problem_types': ['Bug', 'Package'],

并在开头添加一个井号#），它将产生导致崩溃的调用的完整跟踪。无需担心限制在较新版本的 Ubuntu 中，由于阿波特即使设置为 0，也能够规避其指示。

总的来说，最好的办法是将崩溃报告上传到 Launchpad；Apport 会自动执行此操作。但有些信息甚至对没有经验的用户也可能有帮助。上面引用的简介指出：

Some fields warrant further details:

SegvAnalysis: when examining a Segmentation Fault (signal 11), Apport attempts to review the exact machine instruction that caused the fault, and checks the program counter, source, and destination addresses, looking for any virtual memory address (VMA) that is outside an allocated range (as reported in the ProcMaps attachment).

SegvReason: a VMA can be read from, written to, or executed. On a SegFault, one of these 3 CPU actions has taken place at a given VMA that either not allocated, or lacks permissions to perform the action. For example:

SegvReason: reading NULL VMA would mean that a NULL pointer was most likely dereferenced while reading a value.

SegvReason: writing unknown VMA would mean that something was attempting to write to the destination of a pointer aimed outside of allocated memory. (This is sometimes a security issue.)

SegvReason: executing writable VMA [stack] would mean that something was causing code on the stack to be executed, but the stack (correctly) lacked execute permissions. (This is almost always a security issue.)

过去，这曾让我能够精确定位导致崩溃的程序（VirtualBox）。在彻底清除并重新安装后，问题就消失了。我只希望你也能有同样的好运。

Answer 1