如何获得“总线错误”?
I am trying very hard to get a bus error.
One way is misaligned access and I have tried the examples given here and here, but no error for me - the programs execute just fine.
Is there some situation which is sure to produce a bus error?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(12)
这应该能够在 POSIX 兼容系统上可靠地生成
SIGBUS
。根据单一 Unix 规范,mmap:
This should reliably result in a
SIGBUS
on a POSIX-compliant system.From the Single Unix Specification, mmap:
总线错误只能在满足以下条件的硬件平台上调用:
您可能无权访问这样的系统。
Bus errors can only be invoked on hardware platforms that:
You probably do not have access to such a system.
尝试以下方法:(
我知道,可能不是您想要的答案,但几乎肯定会给您带来“总线错误”!)
Try something along the lines of:
(I know, probably not the answer you want, but it's almost sure to get you a "bus error"!)
正如其他人提到的,这是非常特定于平台的。在我正在使用的 ARM 系统(没有虚拟内存)上,有很大一部分地址空间没有分配内存或外设。如果我读取或写入这些地址之一,就会出现总线错误。
如果总线上确实存在硬件问题,您也可能会收到总线错误。
如果您在具有虚拟内存的平台上运行,您可能无法故意使程序生成总线错误,除非它是设备驱动程序或其他内核模式软件。无效的内存访问可能会被内存管理器捕获为访问冲突或类似情况(并且它甚至没有机会访问总线)。
As others have mentioned this is very platform specific. On the ARM system I'm working with (which doesn't have virtual memory) there are large portions of the address space which have no memory or peripheral assigned. If I read or write one of those addresses, I get a bus error.
You can also get a bus error if there's actually a hardware problem on the bus.
If you're running on a platform with virtual memory, you might not be able to intentionally generate a bus error with your program unless it's a device driver or other kernel mode software. An invalid memory access would likely be trapped as an access violation or similar by the memory manager (and it never even has a chance to hit the bus).
在具有 Intel CPU 的 Linux 上尝试此操作:
这里的技巧是在 CPU 的“特殊”寄存器之一中设置“对齐检查”位。
另请参阅:此处
on linux with an Intel CPU try this:
the trick here is to set the "alignment check" bit in one of the CPUs "special" registers.
see also: here
我确信您使用的一定是 x86 机器。
X86 cpu 不会产生总线错误,除非其 EFALAGS 寄存器中的 AC 标志被设置。
尝试此代码:
有关此内容的更多信息,请访问 http://orchistro.tistory.com/206
I am sure that you must be using x86 machines.
X86 cpu does not generate bus error unless its AC flag in EFALAGS register is set.
Try this code:
More about this can be found at http://orchistro.tistory.com/206
另请记住,某些操作系统会针对访问未对齐以外的错误报告“总线错误”。您在问题中没有提到您实际上想要实现的目标是什么。也许可以这样尝试:
您链接到的维基百科页面提到访问不存在的内存也可能导致总线错误。如果将已知无效的地址加载到指针中并取消引用它,您可能会有更好的运气。
Also keep in mind that some operating systems report "bus error" for errors other than misaligned access. You didn't mention in your question what it was you were actually trying to acheive. Maybe try thus:
the Wikipedia page you linked to mentions that access to non-existant memory can also result is a bus error. You might have better luck with loading a known-invalid address into a pointer and dereferwncing that.
这个怎么样?未经测试。
How about this? untested.
总线错误:10(核心已转储)
Bus error: 10 (core dumped)
对于 0x86 arch:
注意:如果删除了 asm 指令,代码将不会像其他人建议的那样生成 SIGBUS 错误。
SIGBUS 也可能因其他原因而发生。
For 0x86 arch:
Note:If asm instructions are removed, code wont generate the SIGBUS error as suggested by others.
SIGBUS can occur for other reason too.
简单,写入不属于您的内存:
在我的 PowerPC Mac [OS X 10.4,双 1ghz PPC7455's] 上出现即时总线错误,不一定是在您的硬件和/或操作系统上。
甚至有一个<一篇关于总线错误的 href="http://en.wikipedia.org/wiki/Bus_error" rel="nofollow noreferrer">wikipedia 文章,包括生成错误的程序。
Simple, write to memory that isn't yours:
Instant bus error on my PowerPC Mac [OS X 10.4, dual 1ghz PPC7455's], not necessarily on your hardware and/or operating system.
There's even a wikipedia article about bus errors, including a program to make one.
如果您尝试访问计算机无法寻址的内存,则会出现总线错误。例如,计算机内存的地址范围为 0x00 到 0xFF,但您尝试访问 0x0100 或更大的内存元素。
实际上,您的计算机的范围将比 0x00 到 0xFF 大得多。
回答您的原始帖子:
在您的代码中,索引到内存的方式超出了最大内存限制的范围。我不知道...使用某种巨大的十六进制值 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 索引到 char* ...
Bus errors occur if you try to access memory that is not addressable by your computer. For example, your computer's memory has an address range 0x00 to 0xFF but you try to access a memory element at 0x0100 or greater.
In reality, your computer will have a much greater range than 0x00 to 0xFF.
To answer your original post:
In your code, index into memory way outside the scope of the max memory limit. I dunno ... use some kind of giant hex value 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indexed into a char* ...