我同意上面所有的答案。以下是我对BUS错误的2点看法:

总线错误不需要由程序代码中的指令引起。这可能发生在您正在运行二进制文件，并且在执行过程中，二进制文件被修改(被构建覆盖或删除等)。

验证是否属实

检查原因的一个简单方法是在构建输出目录中启动两个相同二进制文件的实例，并在它们启动后运行构建。在构建完成并替换二进制文件(两个实例当前正在运行的二进制文件)后不久，这两个正在运行的实例都会崩溃并报出一个SIGBUS错误。

根本原因

这是因为操作系统交换内存页，在某些情况下，二进制文件可能不完全加载在内存中。当操作系统试图从相同的二进制文件中获取下一页时，这些崩溃就会发生，但二进制文件自上次读取以来已经发生了变化。

总线错误的一个典型实例是在某些体系结构上，例如SPARC(至少在某些SPARC上，可能已经更改了)，即当您执行不一致的访问时。例如:

unsigned char data[6];
(unsigned int *) (data + 2) = 0xdeadf00d;

这段代码尝试将32位整型值0xdeadf00d写入(很可能)没有正确对齐的地址，并将在“挑剔”的体系结构上生成总线错误。顺便说一下，Intel x86并不是这样的架构。它将允许访问(尽管执行速度较慢)。

一个值得注意的原因是，如果您试图mmap用户空间不允许访问的/dev/mem区域，则会返回SIGBUS。

导致总线错误的典型缓冲区溢出是:

{
    char buf[255];
    sprintf(buf,"%s:%s\n", ifname, message);
}

在这里，如果双引号("")中的字符串的大小大于buf大小，则会给出总线错误。

我同意上面所有的答案。以下是我对BUS错误的2点看法:

总线错误不需要由程序代码中的指令引起。这可能发生在您正在运行二进制文件，并且在执行过程中，二进制文件被修改(被构建覆盖或删除等)。

验证是否属实

检查原因的一个简单方法是在构建输出目录中启动两个相同二进制文件的实例，并在它们启动后运行构建。在构建完成并替换二进制文件(两个实例当前正在运行的二进制文件)后不久，这两个正在运行的实例都会崩溃并报出一个SIGBUS错误。

根本原因

这是因为操作系统交换内存页，在某些情况下，二进制文件可能不完全加载在内存中。当操作系统试图从相同的二进制文件中获取下一页时，这些崩溃就会发生，但二进制文件自上次读取以来已经发生了变化。

对于我来说，由于没有声明程序集返回到.text部分，我意外触发了“总线错误”。这似乎是显而易见的，但它让我困惑了一段时间。

Eg.

.globl _myGlobal # Allocate a 64-bit global with the value 2
.data
.align 3
_myGlobal:
.quad 2
.globl _main # Main function code
_main:
push %rbp

从数据返回代码时缺少一个文本指令:

_myGlobal:
.quad 2
.text # <- This
.globl _main
_main:

希望这能对某人有所帮助