Talk:Bus error

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Computer hardware task force (assessed as Low-importance).

Terminology

Folks, what constitutes a Bus Error and what is a Segmentation Fault is system-dependent. Linux tends to use Segmentation Fault for things that on other systems might trigger a Bus Error. The article should clarify this.

Secondly, the article gives the impression as if unaligned access typically raises a Bus Error to userland. This is not always true. Some architectures (like the 80386) don't raise an exception at all and handle it transparently, and on other systems it might be configurable. For example, on DEC Unix (Tru64) running on an Alpha, the kernel caught the exception and handled it itself. Typically only a message was printed but I think this could be switched off aswell. Unaligned access causing an error is otherwise typical of RISC processors, while classical CISC architectures transparently did the extra fetch (VAX, 80386).

FWIW, the originaly MC68000 (often cited as a classical CISC implementation) used to choke on unaligned accesses also. Newer members of that family didn't, but it's worth pointing out that this isn't so much a RISC versus CISC issue. 87.194.160.244 (talk) 09:12, 29 May 2009 (UTC)[reply]

Example

Ummm... methinks that your C compiler will make things magically work. As the article mentions: alignment is only required on the *machine level*. However, if your compiler is sane, it seems obvious to me that it will simulate the desired functionality.

 iptr = (int *) &cptr[1];

It may seem obvious to you that it will do that, but you are wrong. The C standard says (6.5.3) "If an invalid value has been assigned to the pointer, the behaviour of the unary * operator is undefined", followed by (in a footnote) "Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime".

You cannot, therefore, expect the C compiler to work around the fact that you are using an inappropriately aligned pointer for you. Indeed, on the systems I have used that raised processor exceptions on unaligned pointer access, that is exactly what will happen if you do such a thing from C. 87.194.160.244 (talk) 09:07, 29 May 2009 (UTC)[reply]

C vs. Java

The article says:

This kind of problem is more likely to occur when the software is written in the C language than in Java.

That's of course true, but it doesn't make any sense to say it like that, because it doesn't offer any explanation why Java is so much better than C. Also it's stupid to say only Java instead of, for example, "languages that don't directly access memory locations, like Java". Opinions? Jsalomaa 19:52, 29 September 2005 (UTC)[reply]

C vs. Java

I think the same. This sentence have to be removed.

Huhhh?

What does this line mean? Is it even necessary?

typ0?

Article says: /* this will cause a bus error - accessing more than bytes from an unaligned address */

Should it be: /* this will cause a bus error - accessing more than one byte from an unaligned address */

Faulty Example

The example C code compiles and runs properly on my FreeBSD4-STABLE (gcc-2.95.4) machine without encountering a Bus Error. Should just remove it until someone can provide example code that consistently reproduces the problem; or at least explain why this example code magically works in some cases.

It works because sizeof(char)==sizeof(int) on your machine I think

On my system (AMD Athlon XP + Fedora 7) I also don't get a "Bus Error". It might be because of the x86 CPU architecture, as hinted to my by the following comment in OpenSSL's fips/sha1/fips_md32_common.h: "This gives ~30-40% performance improvement in SHA-256 compiled with gcc [on P4]. Well, first macro to be frank. We can pull this trick on x86* platforms only, because these CPUs can fetch unaligned data without raising an exception." I do get a "Bus error" on HP-UX. Someone knowledgeable on the subject should definitely update the article!
- I saw your comment, so updated the example to work on x86, as I assume most people who want to try it will run in to the same problems you did. I also included some debugger output to help explain whats happening in the generated code. -- taviso (talk) 04:01, 26 January 2009 (UTC)[reply]

orl $0x40000,(%esp)

What does this instruction do? To me, it looks like it just sets one bit to 1 in esp/rsp (the 3+8+8=19th bit, counted from LSB?). Why would that change alignment checking??? Also, the code does not work on a linux running x86_64 80.87.63.33 (talk) 16:00, 19 November 2019 (UTC)[reply]

I just tested it here with a 32 bits Gentoo Linux on an Intel Core Duo. The exact code does a bus error indeed. But strangely, when I remove the "alignment checking" (pushf ; orl $0x40000,(%esp) ; popf) , it runs without error, and contains the correct value in the (unaligned) target (sizeof(int)==4). So what is the purpose of actually testing alignment if it works when unchecked? Performances? Plain luck? Fafner (talk) 15:29, 21 November 2009 (UTC)[reply]

Performance. Unaligned accesses are silently fixed up on intel, but you suffer a performance penalty. Many other architectures will not silently fix them up, and trap. —Preceding unsigned comment added by 80.218.71.145 (talk) 13:33, 12 December 2009 (UTC)[reply]

Shorter example

int main() {
  int a;
  int *ptr; 

  ptr = malloc(7);
  a = (int)ptr;
  a+=1;
  ptr = (int*)a;

  // crash
  a = *ptr;
}

Another Short Example

Has nothing to do with alignment.

#include <stdio.h>
int
main(void)
{
       char s[10] = "123", *s1 = "456";

       *(s + 1) = '\0';
       printf("s='%s'\n", s);   /* s='1'  */
       *(s1 + 1) = '\0';        /* crash! */
       printf("s1='%s1'\n", s1);

       return 0;
}

The array s[10] is data, and the "123" is stored on the stack.

The value of the pointer s1 is data (and is on the stack), and the "456" can be stored anywhere.

Bus error from paging

You also used to get SIGBUS on x86 if Linux tried to page in code from your executable and failed (any combination of network FS down or credential timeout and long-running tasks was popular). I bet it's still that way. --92.78.17.178 (talk) 16:53, 29 December 2009 (UTC)[reply]

Thanks for mentioning this!

This has been added in the past few years, and is currently located at Bus error#Paging errors.

—Nils von Barth (nbarth) (talk) 01:54, 26 January 2014 (UTC)[reply]

Merge/unmerge to Segmentation fault

This was merged to Segmentation fault in 2010, and I’ve just unmerged it (resplit), per discussion at Talk:Segmentation fault#Bus error. In brief, bus errors and segmentation faults are related but clearly distinct topics – both are memory reference errors, but they are different faults, and have different causes – and both have multiple causes. Putting them in one article results in a complex and confusing mixture of causes, as there are no natural synergies.

That said, the articles should (briefly) explain the connection and distinction from the other fault. I’ll add this shortly.

—Nils von Barth (nbarth) (talk) 02:04, 26 January 2014 (UTC)[reply]

Non-existent address?

Firstly, address cannot be non-existent, it can be invalid (if the memory at that address is non-existent). So the better wording would be "Invalid physical address".

However, what kind of an exception do you assume the CPU will raise when accessing the invalid physical address? To my knowledge there is none: write to non-existent memory does nothing, and read from it will return 0xff (of course if you have not enabled caching for this memory region).

IMHO "Non-existent address" section should be removed. Or, if you know the architecture that does what is described - clarified.

Note that SIGBUS due to alignment is optional and should be enabled with prctl(PR_SET_UNALIGN, PR_UNALIGN_SIGBUS) or the kernel will just decode and simulate the faulted instruction without notifying an application. Plus this doesn't happen on x86 (unless you set the AC flag as your example does), so really the reason for SIGBUS is mostly a paging errors. I wonder why it is started with "FreeBSD, Linux and Solaris" as if other unixes do something else with that most common use of SIGBUS? — Preceding unsigned comment added by 91.103.66.202 (talk) 11:45, 20 September 2017 (UTC)[reply]

Make Example Work?

I tried to make the example work, but activating alignment checking itself triggers an error. — Preceding unsigned comment added by 178.83.38.187 (talk) 12:12, 1 June 2022 (UTC)[reply]