小结 Coredump 之Segmentation faults(段错误) 以及调试和解决方法

 先看一些基本的知识：

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

   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.编程中一般碰到段错误的地方有哪些？

1）往受到系统保护的内存地址写数据

    有些内存是内核占用的或者是其余程序正在使用，为了保证系统正常工做，因此会受到系统的保护，而不能任意访问。
   

   好比对内存地址为0的空间进行操做就会出现这样的问题。

2）内存越界(数组越界，变量类型不一致等)

3）其余

其实大概的缘由都是同样的，就是段错误的定义。可是更多的容易出错的地方就要本身不断积累，不段发现，或者吸纳前人已经积累的经验，而且注意避免再次发生。

例如：

<1>定义了指针后记得初始化，在使用的时候记得判断是否为NULL
<2>在使用数组的时候是否被初始化，数组下标是否越界，数组元素是否存在等
<3>在变量处理的时候变量的格式控制是否合理等

<4>字符串拷贝(strcpy)时必定要检查是否越界，是否会出现内存空间不存在的状况，这种状况在实际的编程状况中常常出现。

 

三、解决和调试错误信息的一些示例：

在UNIX和类UNIX的环境下，支持调试的工具经常使用的有dbx和gdb，掌握这两种工具的使用方法能够大大帮助咱们解决coredump的问题。
下面引用别人的一些示例：

  

 

      咱们在用C/C++语言写程序的时侯，内存管理的绝大部分工做都是须要咱们来作的。实际上，内存管理是一个比较繁琐的工做，不管你多高明，经验多丰富，不免会在此处犯些小错误，而一般这些错误又是那么的浅显而易于消除。可是手工“除虫”（debug），每每是效率低下且让人厌烦的，本文将就"段错误"这个内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。
下面将就如下的一个存在段错误的程序介绍几种调试方法：

1  dummy_function (void)      2  {      3          unsigned char *ptr = 0x00;      4          *ptr = 0x00;      5  }      6      7  int main (void)      8  {      9          dummy_function ();     10     11          return 0;     12  }

做为一个熟练的C/C++程序员，以上代码的bug应该是很清楚的，由于它尝试操做地址为0的内存区域，而这个内存区域一般是不可访问的禁区，固然就会出错了。咱们尝试编译运行它:

xiaosuo@gentux test $ ./a.out 段错误

果真不出所料，它出错并退出了。
1.利用gdb逐步查找段错误:
这种方法也是被大众所熟知并普遍采用的方法，首先咱们须要一个带有调试信息的可执行程序，因此咱们加上“-g -rdynamic"的参数进行编译，而后用gdb调试运行这个新编译的程序,具体步骤以下:

xiaosuo@gentux test $ gcc -g -rdynamic d.c xiaosuo@gentux test $ 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: /home/xiaosuo/test/a.out Program received signal SIGSEGV, Segmentation fault. 0x08048524 in dummy_function () 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文件。后来，忆起为了渐少系统上的拉圾文件的数量（本人有些洁癖，这也是我喜欢Gentoo的缘由之一），禁止了core文件的生成，查看了如下果然如此，将系统的core文件的大小限制在512K大小，再试:

xiaosuo@gentux test $ ulimit -c 0 xiaosuo@gentux test $ ulimit -c 1000 xiaosuo@gentux test $ ulimit -c 1000 xiaosuo@gentux test $ ./a.out 段错误 (core dumped) xiaosuo@gentux test $ ls a.out  core  d.c  f.c  g.c  pango.c  test_iconv.c  test_regex.c

core文件终于产生了，用gdb调试一下看看吧:

xiaosuo@gentux test $ 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_function () at d.c:4 4               *ptr = 0x00;

哇，好历害，仍是一步就定位到了错误所在地，佩服一下Linux/Unix系统的此类设计。
接着考虑下去，之前用windows系统下的ie的时侯，有时打开某些网页，会出现“运行时错误”，这个时侯若是刚好你的机器上又装有windows的编译器的话，他会弹出来一个对话框，问你是否进行调试，若是你选择是，编译器将被打开，并进入调试状态，开始调试。
Linux下如何作到这些呢？个人大脑飞速地旋转着，有了，让它在SIGSEGV的handler中调用gdb，因而第三个方法又诞生了:
3.段错误时启动调试:

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <string.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] == '\n')                 buf[strlen(buf) - 1] = '\0';         snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());         system(cmd);         exit(0); }         void dummy_function (void) {         unsigned char *ptr = 0x00;         *ptr = 0x00; }         int main (void) {         signal(SIGSEGV, &dump);         dummy_function ();         return 0; }

编译运行效果以下:

xiaosuo@gentux test $ gcc -g -rdynamic f.c xiaosuo@gentux test $ ./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_function () 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进行分析:
重写的代码以下:

#include <execinfo.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> /* A dummy function to make the backtrace more interesting. */         void dummy_function (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 frames.\n", size);         for (i = 0; i < size; i++)                 printf ("%s\n", strings[i]);         free (strings);         exit(0); }         int main (void) {         signal(SIGSEGV, &dump);         dummy_function ();         return 0; }

编译运行结果以下：

xiaosuo@gentux test $ gcc -g -rdynamic g.c xiaosuo@gentux test $ ./a.out Obtained 5 stack frames. ./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对应的代码位置:

xiaosuo@gentux test $ objdump -d a.out

8048765:       e8 02 fe ff ff          call   804856c <signal@plt>  804876a:       e8 25 ff ff ff          call   8048694 <dummy_function>  804876f:       b8 00 00 00 00          mov    $0x0,%eax  8048774:       c9                      leave

咱们仍是找到了在哪一个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记: 本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法同样的哦,由于每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。