关于SIGBUS的总结

Bertha 。 2022-08-05 15:28 217阅读 0赞

From: by scz , <Unix编程/应用问答FAQ>

--------------------

2.0 理解SIGBUS与SIGSEGV  
  
Q: SIGSEGV我能理解，但有时碰上SIGBUS，这该如何理解。  
  
A: nkwht@SMTH  
  
nkwht用Google获取这样一些知识。有多种可能导致SIGBUS信号:  
  
1) 硬件故障，不用说，程序员最常碰上的肯定不是这种情形。  
  
2) Linux平台上执行malloc()，如果没有足够的RAM，Linux不是让malloc()失败返回，  
   而是向当前进程分发SIGBUS信号。  
  
   注: 对该点执怀疑态度，有机会可自行测试确认当前系统反应。  
  
3) 某些架构上访问数据时有对齐的要求，比如只能从4字节边界上读取一个4字节的  
   数据类型。IA-32架构没有硬性要求对齐，尽管未对齐的访问降低执行效率。另外  
   一些架构，比如SPARC、m68k，要求对齐访问，否则向当前进程分发SIGBUS信号。  
  
SIGBUS与SIGSEGV信号一样，可以正常捕获。SIGBUS的缺省行为是终止当前进程并产  
生core dump。  
  
A: Marc Rochkind <[rochkind@basepath.com][rochkind_basepath.com] >  
  
SIGBUS与SIGSEGV信号的一般区别如下:  
  
1) SIGBUS(Bus error)意味着指针所对应的地址是有效地址，但总线不能正常使用该  
   指针。通常是未对齐的数据访问所致。  
  
2) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对  
   应该地址。  
  
A: scz <[scz@nsfocus.com][scz_nsfocus.com] > 2002-11-20  
  
参"2.4 如何编程获取栈底地址"中如何捕获SIGBUS与SIGSEGV信号，并利用sigsetjmp、  
siglongjmp重获控制权。  
  
测试表明，在x86/Linux、x86/Solaris、SPARC/Solaris平台上，越过栈底的地址访  
问导致SIGSEGV信号。在x86/FreeBSD、x86/NetBSD、x86/OpenBSD平台上，越过栈底  
的地址访问导致SIGBUS信号，而不是SIGSEGV信号。  
  
下面举例解释一下，什么叫未对齐的数据访问。  
  
\--------------------------------------------------------------------------  
/\*  
\* Test: SPARC/Solaris 8 64-bit kernel mode  
\* gcc -Wall -pipe -g -o bus bus.c  
\*/  
\#include <stdio.h>  
\#include <stdlib.h>  
  
int main ( int argc, char \* argv\[\] )  
\{  
    unsigned int        i = 0x12345678;  
    unsigned short int \*q = NULL;  
    unsigned char      \*p = ( unsigned char \* )&i;  
  
    \*p = 0x00;  
    q  = ( unsigned short int \* )( p + 1 );  
    \*q = 0x0000;  
    return( EXIT\_SUCCESS );  
\}  /\* end of main \*/  
\--------------------------------------------------------------------------  
  
$ ./bus  
总线错误 (core dumped)  
$ gdb ./bus core  
GNU gdb 5.0  
\#0  0x1084c in main (argc=1, argv=0xffbefc54) at bus.c:16  
16          \*q = 0x0000;  
(gdb) disas main  
Dump of assembler code for function main:  
0x10810 <main>   :      save  %sp, -128, %sp  
0x10814 <main+4> :      st  %i0, \[ %fp + 0x44 \]  
0x10818 <main+8> :      st  %i1, \[ %fp + 0x48 \]  
0x1081c <main+12>:      sethi  %hi(0x12345400), %o1  
0x10820 <main+16>:      or  %o1, 0x278, %o0     ! 0x12345678  
0x10824 <main+20>:      st  %o0, \[ %fp + -20 \]  
0x10828 <main+24>:      clr  \[ %fp + -24 \]  
0x1082c <main+28>:      add  %fp, -20, %o0  
0x10830 <main+32>:      st  %o0, \[ %fp + -28 \]  
0x10834 <main+36>:      ld  \[ %fp + -28 \], %o0  
0x10838 <main+40>:      clrb  \[ %o0 \]  
0x1083c <main+44>:      ld  \[ %fp + -28 \], %o0  
0x10840 <main+48>:      add  %o0, 1, %o1  
0x10844 <main+52>:      st  %o1, \[ %fp + -24 \]  
0x10848 <main+56>:      ld  \[ %fp + -24 \], %o0  
0x1084c <main+60>:      clrh  \[ %o0 \]  
0x10850 <main+64>:      clr  %i0  
0x10854 <main+68>:      b  0x1085c <main+76>  
0x10858 <main+72>:      nop  
0x1085c <main+76>:      ret  
0x10860 <main+80>:      restore  
End of assembler dump.  
(gdb) i r pc  
pc             0x1084c  67660  
(gdb) i r o0  
o0             0xffbefbdd       -4260899  
(gdb) x/3bx 0xffbefbdd  
0xffbefbdd:     0x34    0x56    0x78  
(gdb)  
  
从C语言来说，执行"\*q = 0x0000;"时导致SIGBUS了。从汇编指令来说，执行"clrh \[%o0\]"  
时导致SIGBUS了，寄存器%o0值为0xffbefbdd，这个地址未对齐在双字节边界上。  
  
注意，gcc编译时并未指定-O<n>进行优化，但仍然使用clrh，而不是两次clrb。类似  
的汇编指令有ldw、lduh等等。有人可能碰上读操作也导致SIGBUS，觉得不可理解，  
其实读写导致SIGBUS没有本质区别，比如ldw只能读4字节边界上的地址。  
  
bus.c是显式的未对齐。程序员实际最容易面对的是隐式未对齐，主要来自指针的强  
制类型转换。下面举例说明这种情形。  
  
\--------------------------------------------------------------------------  
/\*  
\* Test: SPARC/Solaris 8 64-bit kernel mode  
\* gcc -Wall -pipe -g -o other\_bus other\_bus.c  
\*/  
\#include <stdio.h>  
\#include <stdlib.h>  
  
int main ( int argc, char \* argv\[\] )  
\{  
    unsigned int        i = 0x12345678;  
    unsigned short int  j = 0x0000;  
  
    j = \*( ( unsigned short int \* )( ( ( unsigned char \* )&i  ) + 1 ) );  
    return( EXIT\_SUCCESS );  
\}  /\* end of main \*/  
\--------------------------------------------------------------------------  
  
$ ./other\_bus  
总线错误 (core dumped)  
$ gdb ./other\_bus core  
GNU gdb 5.0  
\#0  main (argc=1, argv=0xffbefc44) at other\_bus.c:13  
13          j = \*( ( unsigned short int \* )( ( ( unsigned char \* )&i  ) + 1 ) );  
(gdb) disas main  
Dump of assembler code for function main:  
0x10810 <main>   :      save  %sp, -120, %sp  
0x10814 <main+4> :      st  %i0, \[ %fp + 0x44 \]  
0x10818 <main+8> :      st  %i1, \[ %fp + 0x48 \]  
0x1081c <main+12>:      sethi  %hi(0x12345400), %o1  
0x10820 <main+16>:      or  %o1, 0x278, %o0     ! 0x12345678  
0x10824 <main+20>:      st  %o0, \[ %fp + -20 \]  
0x10828 <main+24>:      clrh  \[ %fp + -22 \]  
0x1082c <main+28>:      lduh  \[ %fp + -19 \], %o0  
0x10830 <main+32>:      sth  %o0, \[ %fp + -22 \]  
0x10834 <main+36>:      clr  %i0  
0x10838 <main+40>:      b  0x10840 <main+48>  
0x1083c <main+44>:      nop  
0x10840 <main+48>:      ret  
0x10844 <main+52>:      restore  
End of assembler dump.  
(gdb) i r pc  
pc             0x1082c  67628  
(gdb)  
  
因此在SPARC架构上编程，一定要留神强制类型转换，务必清楚自己正在干什么，有  
没有隐患。  
  
D: yuhuan@SMTH 2004-01-30 11:48  
  
参Linux的mmap(2)手册页  
  
\--------------------------------------------------------------------------  
使用映射可能涉及到如下信号  
  
SIGSEGV  
  
    试图对只读映射区域进行写操作  
  
SIGBUS  
  
    试图访问一块无文件内容对应的内存区域，比如超过文件尾的内存区域，或者以  
    前有文件内容对应，现在为另一进程截断过的内存区域。

[  
][Link 1]

--------------------

[版权声明][Link 2] ：转载时请以超链接形式标明文章原始出处和作者信息及[本声明][Link 3]   
[http://bigwhite.blogbus.com/logs/12296535.html][Link 1]

SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个[内存错误][Link 4] 信号。内存问题一直是最令我们头疼的事情，弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。  
  
我们来看两段程序：  
//testsigsegv.c  
int main() \{  
        char \*pc = (char\*)0x00001111;  
        \*pc = 17;  
\}  
  
//testsigbus.c  
int main() \{  
        int \*pi = (int\*)0x00001111;  
        \*pi = 17;  
\}  
  
上面的代码那么的相似，我们也同样用[gcc编译][gcc] (加上-g选项，便于[gdb调试][gdb] ；平台[Solaris][] Sparc)，执行结果也都是[dump core][] 。 但通过GDB对core进行观察，你会发现细微的不同。第一个例子出的core原因是：Program terminated with signal 11, Segmentation fault. 而第二个例子的core则提示：Program terminated with signal 10, Bus error. 两者有什么不同呢？这两段代码的共同点都是将一个非法地址赋值给指针变量，然后试图写数据到这个地址。  
  
如果要说清楚这个问题，我们就要结合[汇编][Link 5] 码和一些计算机的[体系结构][Link 6] 的知识来共同分析了。  
  
先来看testsigsegv.c的汇编码：  
... ...  
main:  
        !\#PROLOGUE\# 0  
        save    %sp, -120, %sp  
        !\#PROLOGUE\# 1  
        sethi   %hi(4096), %i0  
        or      %i0, 273, %i0  
        st      %i0, \[%fp-20\]  
        ld      \[%fp-20\], %i1  
        mov     17, %i0  
        stb     %i0, \[%i1\]  
        nop  
        ret  
        restore  
... ...  
  
我们关注的是这句：stb     %i0, \[%i1\]  
从 计算机底层的执行角度来说，过程是如何的呢？%i0寄存器里存储的是立即数17，我们要将之存储到寄存器%i1的值指向的内存地址。这一过程对于CPU来 说其指挥执行的正常过程是：将寄存器%i0中的值送上数据总线，将寄存器%i1的值送到地址总线，然后使能控制总线上的写信号完成这一向内存写1 byte数据的过程。  
  
我们再看testsigbus.c的汇编码：  
... ...  
main:  
        !\#PROLOGUE\# 0  
        save    %sp, -120, %sp  
        !\#PROLOGUE\# 1  
        sethi   %hi(4096), %i0  
        or      %i0, 273, %i0  
        st      %i0, \[%fp-20\]  
        ld      \[%fp-20\], %i1  
        mov     17, %i0  
        st      %i0, \[%i1\]  
        nop  
        ret  
        restore  
... ...  
  
同 样最后一句：st      %i0, \[%i1\]，CPU执行的过程与testsigsegv.c中的一致(只是要存储数据长度是4字节)，那为什么产生错误的原因不同呢？一个是 SIGSEGV，而另一个是SIGBUS。这里涉及到的就是对内存地址的校验的问题了，包括对内存地址是否[对齐][Link 7] 的校验以及该内存地址是否合法的校验。  
  
我们假设如果首先进行的内存地址是否合法的校验(是否归属于用户进程的地址空间)，那么我们回顾一下，这两个程序中的地址0x00001111显然都不合法，按照这种流程，两个程序都应该是SIGSEGV导致的[core][] 才对，但是事实并非如此。那难道是先校验内存地址的对齐？我们再看这种思路是否合理？  
  
testsigsegv.c 中，0x00001111这个地址值被赋给了char \*pc；也就是告诉CPU通过这个地址我们要存取一个字节的值，对于一个字节长度的数据，无所谓对齐，所以该地址通过对齐校验；并被放到地址总线上了。而 在testsigbus.c里，0x00001111这个地址值被赋给了int \*pi；也就是告诉CPU通过这个地址我们要存取一个起码4个字节的值，那么对于长度4个字节的对象，其存放地址起码要被4整除才可以，而 0x00001111这个值显然不能满足要求，也就不能通过内存对齐的校验。也就是说SIGBUS这个信号在地址被放到地址总线之后被检查出来的不符合对 齐的错误；而SIGSEGV则是在地址已经放到地址总线上后，由后续流程中的某个设施检查出来的内存违法访问错误。

一般我们平时遇到SIGBUS时总是因为地址未[对齐][Link 8] 导致的，而SIGSEGV则是由于内存地址不合法造成的。

转帖：http://blog.csdn.net/codejoker/article/details/4543136

[rochkind_basepath.com]: mailto:rochkind@basepath.com
[scz_nsfocus.com]: mailto:scz@nsfocus.com
[Link 1]: http://bigwhite.blogbus.com/logs/12296535.html
[Link 2]: http://creativecommons.org/licenses/by/3.0/deed.zh
[Link 3]: http://bangzhuzhongxin.blogbus.com/logs/11205960.html
[Link 4]: http://bigwhite.blogbus.com/logs/1559177.html
[gcc]: http://bigwhite.blogbus.com/logs/2062606.html
[gdb]: http://bigwhite.blogbus.com/logs/1801699.html
[Solaris]: http://bigwhite.blogbus.com/logs/10703394.html
[dump core]: http://bigwhite.blogbus.com/logs/2668761.html
[Link 5]: http://bigwhite.blogbus.com/logs/1587340.html
[Link 6]: http://bigwhite.blogbus.com/logs/1649626.html
[Link 7]: http://bigwhite.blogbus.com/logs/2005/08/1347304.html
[core]: http://bigwhite.blogbus.com/logs/10726960.html
[Link 8]: http://bigwhite.blogbus.com/logs/2661330.html