C&C++——段错误（Segmentation fault）

C/C++中的段错误（Segmentation fault）

Segment fault 之因此可以流行于世，是与Glibc库中基本全部的函数都默认型参指针为非空有着密切关系的。
来自:http://oss.lzu.edu.cn/blog/article.php?uid_7/tid_700.html#comment

背景
最近一段时间在linux下用C作一些学习和开发，可是因为经验不足，问题多多。而段错误就是让我很是头痛的一个问题。不过，目前写一个一千行左右的代码，也不多出现段错误，或者是即便出现了，也很容易找出来，而且处理掉。

那什么是段错误？段错误为何是个麻烦事？以及怎么发现程序中的段错误以及如何避免发生段错误呢？

一方面为了给本身的学习作个总结，另外一方面因为至今没有找到一个比较全面介绍这个虽然是“FREQUENTLY ASKED QUESTIONS”的问题，因此我来作个抛砖引玉吧。下面就从上面的几个问题出发来探讨一下“Segmentation faults"吧。

目录
1。什么是段错误？
2。为何段错误这么“麻烦”？
3。编程中一般碰到段错误的地方有哪些？
4。如何发现程序中的段错误并处理掉？

正文
1。什么是段错误？
下面是来自Answers.com的定义：
A segmentation fault (often shortened to segfault) is a particular error condition that can occur during the operation of computer software. In short, a segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (e.g., attempts to write to a read-only location, or to overwrite part of the operating system). Systems based on processors like the Motorola 68000 tend to refer to these events as Address or Bus errors.

Segmentation is one approach to memory management and protection in the operating system. It has been superseded by paging for most purposes, but much of the terminology of segmentation is still used, "segmentation fault" being an example. Some operating systems still have segmentation at some logical level although paging is used as the main memory management policy.

On Unix-like operating systems, a process that accesses invalid memory receives the SIGSEGV signal. On Microsoft Windows, a process that accesses invalid memory receives the STATUS_ACCESS_VIOLATION exception.

另外，这里有个基本上对照的中文解释，来自http://www.linux999.org/html_sql/3/132559.htm
所谓的段错误 就是指访问的内存超出了系统所给这个程序的内存空间，一般这个值是由gdtr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的gdt表， 后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表，在这张表中 就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访 问，cpu就会产生相应的异常保护，因而segmentation fault就出现了

经过上面的解释，段错误应该就是访问了不可访问的内存，这个内存区要么是不存在的，要么是受到系统保护的。

2。为何段错误这么麻烦？
中国linux论坛有一篇精华帖子《Segment fault 之永远的痛》(http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=program&Number=193239&page=2&view=collapsed&sb=5&o=all&fpart=1&vc=1)
在主题帖子里头，做者这么写道：
写程序好多年了，Segment fault 是许多C程序员头疼的提示。指针是好东西，可是随着指针的使用却诞生了这个一样威力巨大的恶魔。

Segment fault 之因此可以流行于世，是与Glibc库中基本全部的函数都默认型参指针为非空有着密切关系的。

不知道何时才能够有可以处理NULL的glibc库诞生啊！

不得已，我如今为好多的函数作了衣服，避免glibc的函数被NULL给感染，致使个人Mem访问错误，而我还不知道NULL这个病毒已经在侵蚀个人身体了。

Segment fault 永远的痛......

后面有好多网友都跟帖了，讨论了Segmentation faults为何这么“痛”，尤为是对于服务器程序来讲，是很是头痛的，为了提升效率，要尽可能减小一些没必要要的段错误的“判断和处理”，可是不检查又可能会存在段错误的隐患。

那么如何处理这个“麻烦”呢？
就像人不可能“完美”同样，由人创造的“计算机语言“一样没有“完美”的解决办法。
咱们更好的解决办法也许是：

经过学习前人的经验和开发的工具，不断的尝试和研究，找出更恰当的方法来避免、发现并处理它。对于一些常见的地方，咱们能够避免，对于一些“隐藏”的地方，咱们要发现它，发现之后就要及时处理，避免留下隐患。

下面咱们能够经过具体的实验来举出一些常常出现段错误的地方，而后再举例子来发现和找出这类错误藏身之处，最后处理掉。

3。编程中一般碰到段错误的地方有哪些？
为了进行下面的实验，咱们须要准备两个工具，一个是gcc，一个是gdb
我是在ubuntu下作的实验，安装这两个东西是比较简单的
sudo apt-get install gcc-4.0 libc6-dev
sudo apt-get install gdb

好了，开始进入咱们的实验，咱们粗略的分一下类

1）往受到系统保护的内存地址写数据
有些内存是内核占用的或者是其余程序正在使用，为了保证系统正常工做，因此会受到系统的保护，而不能任意访问。
例子1：

Code:
#include <stdio.h>
int main(){
int i=0;
scanf("%d",i);
printf("%d\n",i);
return 0;
}
编译和执行一下
$ gcc -o segerr segerr.c
$ ./segerr
10
段错误
咋一看，好像没有问题哦，不就是读取一个数据而后给输出来吗？

下面咱们来调试一下，看看是什么缘由？
$ gcc -g -o segerr segerr.c --加-g选项查看调试信息
$ gdb ./segerr
(gdb) l --用l(list)显示咱们的源代码
1 ＃i nclude <stdio.h>
2
3 int
4 main()
5 {
6 int i = 0;
7
8 scanf ("%d", i);
9 printf ("%d\n", i);
10 return 0;
(gdb) b 8 --用b(break)设置断点
Breakpoint 1 at 0x80483b7: file segerr.c, line 8.
(gdb) p i --用p(print)打印变量i的值[看到没，这里i的值是0哦]
$1 = 0

(gdb) r --用r(run)运行，直到断点处
Starting program: /home/falcon/temp/segerr

Breakpoint 1, main () at segerr.c:8
8 scanf ("%d", i); --[试图往地址0处写进一个值]
(gdb) n --用n(next)执行下一步
10

Program received signal SIGSEGV, Segmentation fault.
0xb7e9a1ca in _IO_vfscanf () from /lib/tls/i686/cmov/libc.so.6
(gdb) c --在上面咱们接收到了SIGSEGV,而后用c(continue)继续执行
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit --退出gdb

果真
咱们“不当心”把&i写成了i
而咱们刚开始初始化了i为0,这样咱们不是试图向内存地址0存放一个值吗？实际上不少状况下，你即便没有初始化为零，默认也多是0，因此要特别注意。

补充：
能够经过man 7 signal查看SIGSEGV的信息。
$ man 7 signal | grep SEGV
Reformatting signal(7), please wait...
SIGSEGV 11 Core Invalid memory reference

例子2：
Code:
#include <stdio.h>
int main(){
char *p;
p = NULL;
*p = 'x';
printf("%c", *p);
return 0;
}
很容易发现，这个例子也是试图往内存地址0处写东西。

这里咱们经过gdb来查看段错误所在的行
$ gcc -g -o segerr segerr.c
$ gdb ./segerr
(gdb) r --直接运行，咱们看到抛出段错误之后，自动显示出了出现段错误的行，这就是一个找出段错误的方法
Starting program: /home/falcon/temp/segerr

Program received signal SIGSEGV, Segmentation fault.
0x08048516 in main () at segerr.c:10
10 *p = 'x';
(gdb)

2）内存越界(数组越界，变量类型不一致等)
例子3：
Code:
#include <stdio.h>
int main(){
char test[1];
printf("%c", test[1000000000]);
return 0;
}
这里是比较极端的例子，可是有时候多是会出现的，是个明显的数组越界的问题，或者是这个地址是根本就不存在的

例子4：
Code:
#include <stdio.h>
int main(){
int b = 10;
printf("%s\n", b);
return 0;
}
咱们试图把一个整数按照字符串的方式输出出去，这是什么问题呢？
因为还不熟悉调试动态连接库，因此我只是找到了printf的源代码的这里声明部分：
int pos =0 ,cnt_printed_chars =0 ,i ;
unsigned char *chptr ;
va_list ap ;
%s格式控制部分：
case 's':
chptr =va_arg (ap ,unsigned char *);
i =0 ;
while (chptr [i ])
{...
cnt_printed_chars ++;
putchar (chptr [i ++]);
}

仔细看看，发现了这样一个问题，在打印字符串的时候，其实是打印某个地址开始的全部字符，可是当你想把整数当字符串打印的时候，这个整数被当成了一个地 址，而后printf从这个地址开始去打印字符，直到某个位置上的值为\0。因此，若是这个整数表明的地址不存在或者不可访问，天然也是访问了不应访问的 内存——segmentation fault。

相似的，还有诸如：sprintf等的格式控制问题
好比，试图把char型或者是int的按照%s输出或存放起来，如：
Code:
#include <stdio.h>
#include <string.h>
int main(){
char c='c';
int i=10;
char buf[100];
printf("%s", c); //试图把char型按照字符串格式输出，这里的字符会解释成整数，
//再解释成地址，因此缘由同上面那个例子
printf("%s", i); //试图把int型按照字符串输出
memset(buf, 0, 100);
sprintf(buf, "%s", c); 试图把char型按照字符串格式转换
memset(buf, 0, 100);
sprintf(buf, "%s", i);//试图把int型按照字符串转换
}


3）其余
其实大概的缘由都是同样的，就是段错误的定义。可是更多的容易出错的地方就要本身不断积累，不段发现，或者吸纳前人已经积累的经验，而且注意避免再次发生。
例如：
<1>定义了指针后记得初始化，在使用的时候记得判断是否为NULL
<2>在使用数组的时候是否被初始化，数组下标是否越界，数组元素是否存在等
<3>在变量处理的时候变量的格式控制是否合理等

再举一个比较不错的例子：

我在进行一个多线程编程的例子里头，定义了一个线程数组
#define THREAD_MAX_NUM
pthread_t thread[THREAD_MAX_NUM];
用pthread_create建立了各个线程，而后用pthread_join来等待线程的结束

刚开始我就直接等待，在建立线程都成功的时候，pthread_join可以顺利等待各个线程结束，可是一旦建立线程失败，那用pthread_join来 等待那个本不存在的线程时天然会存在访问不能访问的内存的状况，从而致使段错误的发生，后来，经过不断调试和思考，而且获得网络上资料的帮助，找到了上面 的缘由和解决办法：

在建立线程以前，先初始化咱们的线程数组，在等待线程的结束的时候，判断线程是否为咱们的初始值
若是是的话，说明咱们的线程并无建立成功，因此就不能等拉。不然就会存在释放那些并不存在或者不可访问的内存空间。

上面给出了很常见的几种出现段错误的地方，这样在遇到它们的时候就容易避免拉。可是人有时候确定也会有疏忽的，甚至可能仍是会常常出现上面的问题或者其余常见的问题，因此对于一些大型一点的程序，如何跟踪并找到程序中的段错误位置就是须要掌握的一门技巧拉。

4。如何发现程序中的段错误？
有个网友对这个作了比较全面的总结，除了感谢他外，我把地址弄了过来。文章名字叫《段错误bug的调试》(http://www.cublog.cn/u/5251/showart.php?id=173718),应该说是很全面的。

而我经常使用的调试方法有：
1）在程序内部的关键部位输出(printf)信息，那样能够跟踪 段错误 在代码中可能的位置
为了方便使用这种调试方法，能够用条件编译指令#ifdef DEBUG和#endif把printf函数给包含起来，编译的时候加上-DDEBUG参数就能够查看调试信息。反之，不加上该参数进行调试就能够。

2）用gdb来调试，在运行到段错误的地方，会自动停下来并显示出错的行和行号
这个应该是很经常使用的，若是须要用gdb调试，记得在编译的时候加上-g参数，用来显示调试信息,对于这个，网友在《段错误bug的调试》文章里创造性的使用 这样的方法，使得咱们在执行程序的时候就能够动态扑获段错误可能出现的位置：经过扑获SIGSEGV信号来触发系统调用gdb来输出调试信息。若是加上上 面提到的条件编译，那咱们就能够很是方便的进行段错误的调试拉。

3）还有一个catchsegv命令
经过查看帮助信息，能够看到
Catch segmentation faults in programs

这个东西就是用来扑获段错误的，它经过动态加载器（ld-linux.so）的预加载机制（PRELOAD）把一个事先写好的库（/lib/libSegFault.so）加载上，用于捕捉断错误的出错信息。
到这里，“初级总结篇”算是差很少完成拉。欢迎指出其中表达不当甚至错误的地方，先谢过!

参考资料[具体地址在上面的文章中都已经给出拉]：
1。段错误的定义
Ansers.com
http://www.answers.com
Definition of "Segmentation fault"
http://www.faqs.org/qa/qa-673.html
2。《什么是段错误》
http://www.linux999.org/html_sql/3/132559.htm
3。《Segment fault 之永远的痛》
http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=program&Number=193239&page=2&view=collapsed&sb=5&o=all&fpart=
4。《段错误bug的调试》
http://www.cublog.cn/u/5251/showart.php?id=173718

后记虽然感受没有写什么东西,可是包括查找资料和打字，也花了好些几个小时，不过总结一下也是值得的，欢迎和我一块儿交流和讨论，也欢迎对文章中表达不当甚至是错误的地方指正一下。