c++ - 段错误代码的可能原因是什么

Question

我最近遇到一个段错误问题，调用删除方法时命中。我深入检查了代码并排除了删除空指针，或多次删除或越界的可能性(分配的内存足够大以容纳之后写入的内容)。这个问题可以重现，每次它在同一个地方出现段错误。

我不知道是什么导致了这个问题。我想知道是否有可能从我得到的错误代码中得到一些线索，例如:-xxxxxxxxxxxxxx 段错误 rip xxxxxxxxxxxxxx rsp xxxxxxxxxxxxxx 错误 4

我在网上搜索了很长时间，只从 stackoverflow 得到了以下有用的信息:-

“错误代码只是页面错误的体系结构错误代码，似乎是体系结构特定的。它们通常记录在内核源代码的 arch/*/mm/fault.c 中。我的 Linux/arch/i386 拷贝/mm/fault.c 对 error_code 的定义如下:

bit 0 == 0 means no page found, 1 means protection fault
bit 1 == 0 means read, 1 means write
bit 2 == 0 means kernel, 1 means user-mode

”

这是我的问题:-错误代码4的可能原因是什么(我的平台是RHEL5 64bit，x86_64)？有什么方法可以从错误代码中判断出可能的原因吗？

关于如何诊断此类问题的任何其他建议也非常感谢!

Answer 1

根据您提供的 arch/i386/mm/fault.c 的文档，错误代码 4 对应于“未找到页面的用户模式读取”。代码 4 = 100 的二进制表示，其中第 2 位是最重要(最左边)的位。

这与在 delete 时收到 SIGSEGV 的最常见原因相吻合:双重释放(尝试释放已释放的指针)。但是，任何堆损坏(例如，通过双重释放其他东西或其他地方的缓冲区溢出/越界错误)都可能是原因。

尝试在 valgrind 下运行代码(使用调试符号编译)或使用内存分配例程的调试版本运行(在环境中将 MALLOC_CHECK_ 设置为 1 或 2在您的二进制文件运行之前)，两种不同的方法都试图捕获这些错误并在它们发生后立即向您报告。

valgrind 的内存模型非常详尽，如果启用适当数量的检查，几乎肯定会找到问题的根源。

MALLOC_CHECK_ 是 glibc 内部的，与大多数不是 valgrind 的内存调试检测工具一样，它只能捕获某些类型的相对常见的错误并检测堆在某些情况下腐败。还有许多其他工具，如 MALLOC_CHECK_(例如 Electric Fence)，但前者已经内置到您的 C 库中，而其他工具最多需要他们的库(这包含 malloc 和 free 覆盖，主要是)使用 LD_PRELOAD 在 C 库之前动态链接。

请注意，在空指针上使用 C++ delete 在技术上不是问题，因此您可以从核对表中划掉那个(我猜您可能已经这样做了，方法是修改代码在删除之前明确检查)。

更多详情:

对应于“未找到页面的用户模式读取”的错误代码意味着指向内存的指针(一些 32/64 位数字指的是虚拟地址空间中的某处)被取消引用(即，一些代码尝试读取指针持有的虚拟内存地址处的值)但是内核页表表明虚拟地址指的是[内存]页面，该页面要么未映射到您的进程中，要么自那以后从您的进程中取消映射指针有效。除了可以想象这种情况发生的明显方式之外，它还可能由于损坏的堆(其中包含各种幕后记账信息)而间接发生:例如，指针算法可能会对您传递给的值进行delete 使用另一个早先损坏的堆内部指针，然后导致指针中有一个无效值，等待代码尝试使用它。

换句话说，内核错误代码在常见的调试场景中确实帮不了你太多。

我假设您已经在 gdb 下运行了您的程序，并且只是在崩溃前几行设置了一个断点，以观察被删除的指针的值和周围状态的其余部分。

编辑:

当我显然是指 MALLOC_CHECK_ 时，删除了错误的 -g2 引用。为您添加了进一步的诊断问题和解释。