在 x86 Linux 上调试 SIGBUS

问题描述：

什么会导致 Linux 中通用 x86 用户空间应用程序出现 SIGBUS（总线错误）？我在网上找到的所有讨论都是关于内存对齐错误的，据我所知，这并不适用于 x86。

（我的代码在Geode上运行，以防那里存在任何相关的处理器特定的怪癖。）

解决方案 1：

SIGBUS除了内存对齐错误之外，在 Linux 中还可能由于很多原因发生这种情况 - 例如，当您尝试访问mmap映射文件末尾以外的区域时。

您是否使用类似mmap共享内存区域或类似的东西？

解决方案 2：

如果打开未对齐访问陷阱，则可以从未对齐的访问中获取 SIGBUS，但在 x86 上通常将其关闭。如果出现某种错误，也可以通过访问内存映射设备获取它。

最好的办法是使用调试器来识别错误指令（SIGBUS 是同步的），并尝试了解它正在尝试做什么。

解决方案 3：

x86（包括 x86_64）Linux 上的 SIGBUS 是一种罕见的野兽。它可能出现在尝试访问 ed 文件末尾之后mmap，或 POSIX 描述的某些其他情况中。

但是从硬件故障中获取 SIGBUS 并不容易。也就是说，任何指令（无论是否是 SIMD）的未对齐访问通常都会导致 SIGSEGV。堆栈溢出会导致 SIGSEGV。即使访问非规范形式的地址也会导致 SIGSEGV。所有这些都是由于引发了 #GP，它几乎总是映射到 SIGSEGV。

现在，这里有一些由于 CPU 异常而获取 SIGBUS 的方法：

1. 启用 中的 AC 位EFLAGS，然后通过任何内存读取或写入指令进行未对齐访问。有关详细信息，请参阅此讨论。

2. 通过堆栈指针寄存器（rsp或rbp）进行规范违反，生成#SS。以下是 GCC 的示例（使用 进行编译gcc test.c -o test -masm=intel）：

int 主要()
{
    __asm__("mov rbp,0x400000000000000
"
            “mov rax，[rbp] 
”
            “ud2  n”）；
}

解决方案 4：

哦，是的，还有一种更奇怪的方法可以获取 SIGBUS。

如果内核由于内存压力（必须禁用 OOM killer）或 IO 请求失败而无法调入代码页，则会发出 SIGBUS。

解决方案 5：

当您从 NFS（网络文件系统）运行二进制文件并且文件发生更改时，您可能会看到 SIGBUS。请参阅https://rachelbythebay.com/w/2018/03/15/core/。

解决方案 6：

上面曾简要提到过这是一个“失败的 IO 请求”，但我将稍微扩展一下。

常见的情况是，当您使用 ftruncate 缓慢地增大文件大小，将其映射到内存中，开始写入数据，然后文件系统中的空间耗尽时。映射文件的物理空间在页面错误时分配，如果没有剩余空间，则进程会收到 SIGBUS。

如果您需要应用程序正确地从此错误中恢复，则在使用 fallocate 进行 mmap 之前明确保留空间是有意义的。在 fallocate 调用后处理 errno 中的 ENOSPC 比处理信号要简单得多，尤其是在多线程应用程序中。

解决方案 7：

mmap如果您请求由带有标志的大页面支持的映射MAP_HUGETLB，则可以知道SIGBUS内核是否用尽了分配的大页面，从而无法处理页面错误。

在这种情况下，你需要通过以下方式增加分配的大页面数量

• /sys/kernel/mm/hugepages/hugepages-<size>/nr_hugepages或者

• /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/nr_hugepages在 NUMA 系统上。

解决方案 8：

x86 Linux 上总线错误的一个常见原因是尝试取消引用并非真正指针或野指针的内容。例如，无法初始化指针，或将任意整数分配给指针然后尝试取消引用它通常会产生分段错误或总线错误。

对齐确实适用于 x86。尽管 x86 上的内存是字节寻址的（因此你可以将字符指针指向任何地址），但如果你有一个指向 4 字节整数的指针，则该指针必须对齐。

您应该在 gdb 中运行您的程序并确定哪个指针访问产生了总线错误以诊断问题。

解决方案 9：

这有点偏离常规，但你可以从未对齐的 SSE2 (m128) 负载中获取 SIGBUS。