如何确定“BUS-Error”的原因
Posted
技术标签:
【中文标题】如何确定“BUS-Error”的原因【英文标题】:How to determine the cause for "BUS-Error" 【发布时间】:2016-05-01 18:06:06 【问题描述】:我正在开发一个带有 yocto 发行版和 python 2.7.3 的 variscite 板。
我有时会收到来自 python 解释器的总线错误消息。 我的程序在错误发生前至少几个小时或几天正常运行。 但是当我得到它一次时,我尝试重新启动程序时直接得到它。 在系统再次工作之前,我必须重新启动。
我的程序只使用了一个串口、一个 USB 通信和一些 tcp 套接字。
我可以切换到另一个硬件并遇到同样的问题。
我还使用了 python 自测 python -c "from test import testall"
我得到这两个测试的错误
test_getattr (test.test_builtin.BuiltinTest) ... 错误 test_nameprep (test.test_codecs.NameprepTest) ... 错误
自检总是在
test_callback_register_double (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... 分割 故障
但是当系统运行几个小时时,自测会提前停止
ctypes.macholib.dyld 总线错误
我用memtester检查了内存,好像没问题。 如何找到问题的原因?
【问题讨论】:
memtester 是个好主意,但您可能需要检查内核消息 (dmesg
)。几周前我最后一次(也是第一次)遇到“总线错误”是在运行一些 git 命令时,但它可能是任何事情,因为根本原因显然是我的硬盘驱动器死了,正如内核跟踪所显示的那样,所以我会说这也可能是你的闪光灯。
在运行 linux 的现代系统上,总线错误通常来自尝试执行未对齐的内存访问。这通常发生在 C 程序员认为他们很聪明的时候,将一些任意指针转换为大于 char
的类型,例如懒于对文件或套接字读/写缓冲区进行序列化/反序列化。您的整个程序实际上是用 Python 编写的,还是只是将 Python 用作测试框架?当您遇到总线错误时,您可以将调试器附加到进程并回溯吗?
【参考方案1】:
总线错误通常是由应用程序试图访问硬件无法物理寻址的内存引起的。在您的情况下,存在分段错误,这可能会导致取消引用错误指针或类似的东西,从而导致访问物理上不可寻址的内存地址。我会从根源开始首先导致分段错误,因为总线错误是次要症状。
【讨论】:
【参考方案2】:一年后,我找到了问题的间接原因。
我写了一个 crc16 模块,它使用:
from ctypes import c_ushort
...
value = c_ushort(crcValue >>8 ) ...
如果出现 BUS 错误,这是有问题的部分。
我不认为 c_ushort() 函数本身会导致问题,它只是表明有问题的函数。
升级系统到Linux version 3.14.38-6QP+g8740b9f (test@Yocto) (gcc version 4.9.2 (GCC) )
后问题消失
【讨论】:
以上是关于如何确定“BUS-Error”的原因的主要内容,如果未能解决你的问题,请参考以下文章