SIGBUS on x86 Linux is rare, but it appears, the call stack is often confusing, plus the difference between the signal system platforms larger problem, even more difficult to sort out, summarize a little here about the x86 Linux What circumstances would trigger BUS ERROR.
Mapping file access exception
This is the most common SIGBUS in user mode scenarios and most likely trigger, in general, are the root causes of process mmap a file, another process this document cut off, resulting in mmap out some memory pages beyond file the actual size of the memory access those pages exceeded will trigger SIGBUS, specifically, it is the following scenario:
1, after the process mmap a file, other processes to truncate the file smaller.
2, dynamic database updates, direct cp coverage.
3, the executable file is updated, cp direct coverage.
The system reads the disk file is usually in pages mapped into memory, for efficiency often use copy on write mechanism, so after file mapping, if the corresponding file page does not exist (truncated), may not be the problem right away, only when to visit will make mistakes, so there is a certain lag.
Unaligned memory access
When accessing unaligned memory on the X86 platform, the default will not be a problem, but the user can manually set the EFLAGS the CPU is set to unaligned memory access is not allowed at this time if unaligned memory access occurs, SIGBUS throws, specific examples of reference [3].
Stack fault exception
This scenario is very rare, usually OS or memory hardware problems, intel developer files from the point of view, this anomaly belong trap, not something we often say that the user mode exception, there are three causes of this anomaly [4]:
1 , Canonical address Violation.
Canonical address refers to the 64-bit mode, the high address 48 to address 64 are not all 0 or 1.
If the non-canonical address accessed by the kernel stack pointer will send rbp or rsp stack fault trap, the following sample code:
Note that only the stack pointer operation will SIGBUS, non-stack pointer caused such an exception will only throw SIGSEG.
2, the stack pointer operation referenced address is outside the stack size.
I'm not reproduce this type of operation method, but said the document can be triggered.
3, stack operations referenced stack segment does not exist.
Such operations are generally kernel or compiler bug.
To sum up, stack fault must be related to the rsp / rbp this stack pointer operation, usually the user is unlikely to trigger state, if not mmap-related abnormalities, most likely kernel or a hardware problem (here are some absolute), such exceptions usually results in the following core outputs a message at / var / log / messages:
Quote
[1] https://stackoverflow.com/questions/2089167/debugging-sigbus-on-x86-linux
[2] http://orchistro.tistory.com/206
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=11357
[4] https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf