linux中段错误的处理
在Linux环境下做C语言项目，由于是在一个原有项目基础之上进行二次开发，而且项目工程庞大复杂，出现了不少问题，其中遇到最多、花费时间最长的问题就是著名的“段错误”（Segmentation Fault）。借此机会系统学习了一下，这里对Linux环境下的段错误做个小结，方便以后同类问题的排查与解决。1. 段错误是什么

一句话来说，段错误是指访问的内存超出了系统给这个程序所设定的内存空间，例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。这里贴一个对于“段错误”的准确定义（参考Answers.com）：

1.利用gdb逐步查找段错误:
需要一个带有调试信息的可执行程序，加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:
$ gcc -g -rdynamic d.c
$ gdb ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: /a.out

Program received signal SIGSEGV, Segmentation fault.
0x08048524 in dummy_ () at d.c:4
4 *ptr = 0x00;
(gdb)

不用一步步调试就找到了出错位置d.c文件的第4行。
发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man 7 signal)，
SIGSEGV默认handler的动作是打印”段错误"的出错信息，并产生Core文件，由此又产生了方法二。2.分析Core文件：
Core文件是什么呢？The default action of certain signals is to cause a process to terminate and produce a core dump file,
a disk file containing an image of the process's memory at the time of termination.
A list of the signals which cause a process to dump core can be found in signal(7).以 上资料摘自man page(man 5 core)。有时为了渐少系统上的拉圾文件的数量，禁止了core文件的生成，
将系统的core文件的大小限制在512K大小$ ulimit -c 0
$ ulimit -c 1000
$ ulimit -c 1000
$ ./a.out
段错误 (core dumped)
$ ls
a.out core d.c f.c g.c pango.c test_iconv.c test_regex.ccore文件终于产生了，gdb调试:$ gdb ./a.out core
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: 输入/输出错误.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x08048524 in dummy_ () at d.c:4
4 *ptr = 0x00;windows系统下的ie的，有时打开某些网页，会出现“运行时错误”，这个时侯如果恰好你的机器上又装有windows的编译器的话，
它会弹出来一个对话框，问你是否进行调试，如果你选择是，编译器将被打开，并进入调试状态，开始调试。
Linux下如何做到这些？让它在SIGSEGV的handler中调用gdb，于是第三个方法又诞生了:3.段错误时启动调试:

#include <stdio.h>
#include<stdlib.h>
#include<string.h>
#include<signal.h>

void dump(int signo)
{
char buf[1024];
char cmd[1024];

FILE* fh;

snprintf(buf, sizeof(buf),
"/proc/%d/cmdline", getpid());
if(!fh = fopen(buf, "r"))
exit(0);
if(!fgets(buf, sizeof(buf), fh))
exit(0);
fclose(fh);
if(buf[strlen(buf-1)] = '\0')
buf[strlen(buf) - 1] = '\0';
snprintf(cmd, sizeof(cmd),
"gdb %s %d", buf, getpid());
system(cmd);
exit(0);
}//dump

void
dummy(void)
{
unsigned char* ptr = 0x00;
*ptr = 0x00;
}//dummy

int
main(void)
{
signal(SIGSEGV, &dump);
dummy();

return 0;
}//main

编译运行效果如下:

$ gcc -g -rdynamic f.c
$ ./a.out
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /home/xiaosuo/test/a.out, process 9563
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ee4b53 in waitpid () from /lib/libc.so.6
#2 0xb7e925c9 in strtold_l () from /lib/libc.so.6
#3 0x08048830 in dump (signo=11) at f.c:22
#4 <signal handler called>
#5 0x0804884c in dummy_ () at f.c:31
#6 0x08048886 in main () at f.c:38

以上方法都是在系统上有gdb的前提下进行的，如果没有呢？其实glibc提供了此类能够dump栈内容的函数簇，
详见/usr/include/execinfo.h（这些函数都没有提供man page，难怪我们找不到），另外也可以通过gnu的手册进行学习。
4.利用backtrace和objdump进行分析:
重写的代码如下:
＃i nclude <execinfo.h>
＃i nclude <stdio.h>
＃i nclude <stdlib.h>
＃i nclude <signal.h>


void
dummy_ (void)
{
unsigned char *ptr = 0x00;
*ptr = 0x00;
}

void dump(int signo)
{
void *array[10];
size_t size;
char **strings;
size_t i;

size = backtrace (array, 10);
strings = backtrace_symbols (array, size);

printf ("Obtained %zd stack s.\n", size);

for (i = 0; i < size; i++)
printf ("%s\n", strings[i]);

free (strings);

exit(0);
}

int
main (void)
{
signal(SIGSEGV, &dump);
dummy_ ();

return 0;
}

编译运行结果如下：
$ gcc -g -rdynamic g.c
$ ./a.out
Obtained 5 stack s.
./a.out(dump+0x19) [0x80486c2]
[0xffffe420]
./a.out(main+0x35) [0x804876f]
/lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866]
./a.out [0x8048601]

用objdump反汇编程序,找到地址0x804876f对应的代码位置:
$ objdump -d a.out
8048765: e8 02 fe ff ff call 804856c <signal@plt>
804876a: e8 25 ff ff ff call 8048694 <dummy_>
804876f: b8 00 00 00 00 mov $0x0,%eax
8048774: c9 leav