Bus error vs Segmentation fault

Difference between a bus error and a segmentation fault? Can it happen that a program gives a seg fault and stops for the first time and for the second time it may give a bus error and exit ?

From stackoverflow

• I assume you're talking about the SIGSEGV and SIGBUS signals defined by Posix.

  SIGSEGV occurs when the program references an invalid address. SIGBUS is an implementation-defined hardware fault. The default action for these two signals is to terminate the program.

  The program can catch these signals, and even ignore them.

• For instance, a bus error might be caused when your program tries to do something that the hardware bus doesn't support. On SPARCs, for instance, trying to read a multi-byte value (such as an int, 32-bits) from an odd address generated a bus error.

  Segmentation faults happen for instance when you do an access that violate the segmentation rules, i.e. trying to read or write memory that you don't own.

  Thunderboltz : what do mean when you say "read or write memory that you don't own ? " when you do a malloc you have allocated like say 5 bytes of memory. If you read/write memory you don't own it does not give you a Seg fault in C.

  Geek : On the contrary overwriting a memory owned by some other object in the same address space gives a Segmentation fault ??

  David Schmitt : "What you own" on the OS level is typically much more than what the runtime surfaces (e.g. via malloc) to you. Thus there is much space for memory to access which you own, but still shouldn't and there is much address space which you may read, but not write (most mapped libraries) as well as specific functions to write protect memory regions (mprotect).

  David Schmitt : @Geek: the OS has no way of knowing "who" is doing the write within the same address space. Thus it cannot protect you from overwriting memory within the same program. That's the reason why most security exploits work.

  unwind : I obviously suck, compared to Pax and Bastien. :) But yeah, @Thunderboltz, as other commenters (and P&B) explained, segfaults happen when you try to access memory that doesn't belong to you.

• On most architectures I've used, the distinction is that:

  • a SEGV is caused when you access memory you're not meant to (e.g., outside of your address space).
  • a SIGBUS is caused due to alignment issues with the CPU (e.g., trying to read a long from an address which isn't a multiple of 4).
  bk1e : Memory mapped files can also generate SIGBUS.

• This would be a dup of What is a bus error?, if it weren't for the

  Can it happen that a program gives a seg fault and stops for the first time and for the second time it may give a bus error and exit ?

  part of the question. You should be able to answer this for yourself with the information found here.

  ---

  Insanity: doing the same thing over and over again and expecting different results.
  -- Albert Einstein

  ---

  Of course, taking the question literally...

  #include <signal.h>
  #include <stdlib.h>
  #include <time.h>
  #include <unistd.h>
  int main() {
      srand(time(NULL));
      if (rand() % 2)
          kill(getpid(), SIGBUS);
      else
          kill(getpid(), SIGSEGV);
      return 0;
  }
  

  Tada, a program that can exit with a segmentation fault on one run and exit with a bus error on another run.

• Interpreting your question (possibly incorrectly) as meaning "I am intermittently getting a SIGSEGV or a SIGBUS, why isn't it consistent?", it's worth noting that doing dodgy things with pointers is not guaranteed by the C or C++ standards to result in a segfault; it's just "undefined behaviour", which as a professor I had once put it means that it may instead cause crocodiles to emerge from the floorboards and eat you.

  So your situation could be that you have two bugs, where the first to occur sometimes causes SIGSEGV, and the second (if the segfault didn't happen and the program is still running) causes a SIGBUS.

  I recommend you step through with a debugger, and look out for crocodiles.

• SIGBUS will also be raised if you mmap() a file and attempt to access part of the mapped buffer that extends past the end of the file, as well as for error conditions such as out of space. If you register a signal handler using sigaction() and you set SA_SIGINFO, it may be possible to have your program examine the faulting memory address and handle only memory mapped file errors.