我目前正在开发一个在经过大量修改的 Linux 版本上运行的项目，该版本已修补以能够访问 VMEbus。大多数总线处理已经完成，我有一个 VMEAccess 类，它使用 mmap 在 /dev/mem 的特定地址写入，因此驱动程序可以提取该数据并将其推送到总线上。

当程序启动时，它不知道它要寻找的从板在总线上的位置，所以它必须通过四处寻找它：它尝试一个一个地读取每个地址，如果一个设备连接在那里，则读取方法返回一些数据，但如果没有任何连接，则将向程序发送 SIGBUS 信号。

我尝试了几种解决方案（主要使用信号处理），但一段时间后，我决定使用跳转。第一个 longjmp() 调用工作正常，但对 VMEAccess::readWord() 的第二个调用给了我一个总线错误，即使我的处理程序应该防止程序崩溃。

这是我的代码：

我目前正在尝试解决 K+R 书中的练习 2.4，但遇到了一个我无法在其他地方真正重现的奇怪错误。我在用着：

代码是：

GDB 说：

该错误最初发生在s1[j++] = s1[i]，但我插入s1[0] = s1[0]以独立于变量进行测试，并且它也发生在那里。显然，我在这里遗漏了一些东西。

clang -O0 -g -Weverything exercise2-4.c -o exercise2-4如果这有任何相关性，我正在编译。

非常感谢您抽出宝贵的时间，如果这个问题之前已经回答过，我很抱歉，我还没有发现任何问题发生在这样一个奇怪的地方。

动机

我正在努力提高我对Xwayland 中的 SIGBUS 错误的理解。自 2018 年 2 月 20 日左右以来，一些 Fedora Linux 用户已经看到了这种情况，使用Xwayland 1.19.6-5.fc27.x86_64Linux 内核4.15.3-300.fc27.x86-64。

遗憾的是，我没有内核“segfault”日志消息（或 SIGBUS 的等价物）。Xwayland 有一些毫无意义的代码可以捕获致命信号。但是我可以siginfo通过调试 coredump 看到，这似乎几乎一样好。

定义

我了解当 RAM 中的一页虚拟内存不可用且必须从磁盘读取时，会发生“重大页面错误”。对于这个问题，我想我对由 ext4 文件系统支持的页面（例如，不能直接访问块设备）特别感兴趣。

因此，“次要页面错误”是指无需访问磁盘。我认为差异是相当明确的，因为 Linux 公开了主要和次要页面错误的计数器。

我的问题

如果内核发送一个程序 SIGBUS，我想知道我是否应该普遍认为这将是一个主要的页面错误。

根据 coredump 和反汇编，程序在接收到 SIGBUS 时是在读取内存，而不是在写入。中的故障地址位于siginfo->si_addr映射的系统可执行文件中，用户不可写入，并且该地址似乎在当前文件长度的范围内。事实上，在调试 coredump 时，我已经从内存地址中读取了非常有说服力的值。看起来核心转储生成过程读取这个地址没有困难:-(。

我也有信心排除“无效地址对齐”情况（BUS_ADRALN），因为siginfo->si_code是2，即BUS_ADRERR，“不存在的物理地址”。还因为我在 x86 上，在大多数情况下允许未对齐的访问，并且陷阱不在任何 SSE 扩展指令中。

我考虑了内核在处理它确定为“次要”的页面错误时通常负责的内容。我想小故障可能无法分配内存，因此会引发 SIGBUS。但是，我相信我会注意到这样的分配失败：

我有足够的免费交换空间来驱逐用户页面，我没有注意到当我的系统开始交换时通常会出现明显的减速。崩溃发生在将笔记本电脑从挂起状态唤醒到 ram 后几秒钟，即使在 ~100MB/s 的情况下，这也不足以填充 8GB 的​​交换空间。我也没有看到内核日志中出现可怕的内存不足 (OOM) 杀手，正如我所期望的，如果内核未能分配页框或页表。

是否存在其他一些可能导致轻微页面错误失败并导致 SIGBUS 的可能性？即在内核日志中查找错误时，是否有一些我不会注意到的原因？哪个可以快速发作？

同样，多个 coredump 将其显示为通过从文件系统上的映射文件读取而触发的页面错误。

不可告人的动机

我真的很想错过一个小页面错误的案例。因为这可怕的另一面是我不明白这个 SIGBUS 是如何由硬页面错误方面引起的。从几个月前开始，我们中的一些用户出现了看起来非常相似的错误。我的内核日志中没有 IO 错误。在正常操作期间，读取指示的文件时没有 IO 错误。rpm --verify --all运行时或在 HDD 上运行扩展 SMART 测试时没有错误。不幸的是，我似乎很少有嫌疑人。最接近的怀疑我有一个内核升级，我显然更愿意排除它；日期并不能完全证明这一点，但也不能完全排除。最接近日期的是今年的微码更新；这似乎更难确定。

次要页面错误的已知原因

1. 从逻辑上讲，在为 MAP_PRIVATE 映射实现写时复制时，这听起来像是发生了轻微的页面错误。
2. 它还应该包括 /dev/zero 或 MAP_ANONYMOUS 上的读取错误，假设内核没有将它们实现为读取共享零页面并且没有实现它们以立即为整个映射分配页面。

3. 但更一般地说，它可以是对页面的任何首次访问。这是因为似乎内存映射的页表通常是按需填充的。（这将由页面错误完成，如果文件页面已经在缓存中，则它只是一个次要的页面错误）。

   MAP_NONBLOCK（自 Linux 2.5.46 起）

   此标志仅与 MAP_POPULATE 一起有意义。不要执行预读：仅为已存在于 RAM 中的页面创建页表条目。从 Linux 2.6.23 开始，这个标志会导致 MAP_POPULATE 什么都不做。有一天，MAP_POPULATE 和 MAP_NONBLOCK 的组合可能会被重新实现。

编辑：进一步摘录详细说明上述内容

一位评论者要求提供更具体的细节，以澄清故障地址和说明。初始链接中有很多摘录https://bugzilla.redhat.com/show_bug.cgi?id=1557682

故障因错误链接中所述而异。以下是最近一个例子的新鲜摘录。

reloc->r_info请注意，此指令根据突出显示的源代码行获取值。

错误地址属于下面的文本映射（来自maps捕获的文件abrtd）：

我有一个 Zynq UltraScale MPSoC，上面有一个运行 Linux 的四核 ARM Cortex。有时，有一个事件会产生 SIGBUS 错误。我在下面包含了调试分析的片段。我确信 dst 和 src 的值在合法区域内。实际访问本身是从 FPGA 内存资源到内部 ARM 内存位置的复制例程。

我在另一篇文章中读到 SIGBUS in 的原因可能是 I/O 故障。任何人都可以扩展与 ARM 相关的“I/O 故障”吗？我设想，类似于失败的总线确认。

相对于 ARM Cortex，是否存在与机器检查寄存器等效的功能，可以进一步了解 SIGBUS 的原因？

请有人帮助解决 arm 上的以下共享内存问题，为什么 memset 失败？

内核架构 - aarch64

用户拱门 - 手臂

每次 dolagent.app 运行时，都会发生 sigbus err，backtrace with core 显示 memset 是最后一行，

代码：

注意：struct showTechElements 是用__attribute((aligned (4))).

sizeof(showTechElementT)会得到192

我有一个运行时间很长的 python 脚本，它可以跨不同系统同步数据。它执行大量数据检索、数据转换、HTTP 请求以及所有这些部分多线程的工作。

该脚本有时会产生 SIGBUS / SIGILL 错误，我不知道如何正确处理它们。

该程序以线程方式处理大约 500 个项目。每个项目都是这样的字典。

现在我以前从未遇到过 SIGBUS 或 SIGILL，但是在阅读了一些内容之后，我发现这种严重的事情与我在这里线程化并且线程试图访问另一个线程破坏的东西有关？

我正在运行一个使用 .f90 的 fortran 代码来进行自然对流的腔研究。但是我遇到了上述错误。

我的代码如下所示：

编译器能够编译代码，所以我不确定代码中出了什么问题。希望有人可以帮助我。

代码的更多细节：

编辑 1：示例程序的平台是 x86_64。

编辑2：我正在编辑这个以便更好地理解。下面是两个不同的问题。第一个问题是无效的读/写会导致 SIGBUS 吗？第二个问题是 Valgrind 对 SIGBUS 分析有用吗？示例代码用于第二个问题，以支持我的观点，即 Valgrind 在 SIGBUS 错误的情况下根本没有用。我在这里可能错了。

实际场景：我们有一个屏幕阅读器应用程序在连续测试 2 天后崩溃（由于 SIGBUS 曾经崩溃）。我有一个 coredump 文件，但我没有正确的二进制和调试包。所以基本上我必须在不同的二进制文件中测试它，并且由于调试包不匹配，coredump 在 gdb 中无法正常工作。在 Valgrind 分析期间，我可以在屏幕阅读器模块中看到一些无效的读/写。我的队友建议通过修复这些无效的读/写来解决这个问题，但我认为它不会解决它。以下是我对这两个信号的理解。

SIGSEGV：地址有效，但没有读/写权限。

SIGBUS：地址本身无效（CPU由于未对齐等原因无法找到地址）

我有一个与 SIGBUS 信号有关的问题。我已经搜索了有关堆栈溢出的类似问题，但没有找到任何明确的答案。

无效的读/写会导致总线错误（SIGBUS）吗？.

我的理解是无效的读/写总是会导致分段错误（SIGSEGV），修复总线错误的最佳方法是在应用程序上运行 gdb。在总线错误的情况下进行 Valgrind 分析根本没有帮助。下面的代码更详细地解释了这一点。

在分段错误的情况下，Valgrind 报告将包含有关导致崩溃的代码的详细信息，但在 SIGBUS 崩溃的情况下，我在 Valgrind 报告中没有找到任何此类详细信息。

SIGSEGV 的 Valgrind 报告：

SIGBUS 的 Valgrind 报告：

这不是一个问题，而是一个我以前在这里找不到的问题的答案。

我有一个应用程序不断崩溃并显示“总线错误”消息。这在我的代码的不同部分不确定地发生，通常是在长时间运行之后。唯一的提示是关联的 si_code，是“BUS_ADRERR：不存在的物理地址”。

崩溃的原因是我会重新编译代码，从而弄乱了可执行文件的内存映射。

我有三个不同的过程。它们都有自己的信号处理程序。所有处理程序都有自己的日志。我用另一个进程人为地创建信号。我在控制台中只看到了一个处理程序的日志。我希望看到所有的日志。行为是否正确？