段错误总结

最近试着写了华为编程大赛的程序，出现较多的一个问题是段错误，由此看来对指针与边界的处理还不熟练。网上有些总结的很不错，因此结合网上资料整理下。（下面的还有些地方没有深究，有时间继续深入研究）

http://www.cnblogs.com/lidabo/p/4545625.html

一、段错误是什么

一句话来说，段错误是指访问的内存超出了系统给这个程序所设定的内存空间，例如访问了不存在的内存地址、访问了系统保护的内存地址、访问了只读的内存地址等等情况。

二、段错误产生的原因

1、访问不存在的内存地址

#include<stdio.h>#include<stdlib.h>void main(){  int *ptr = NULL;  *ptr = 0;}

2、访问系统保护的内存地址

#include<stdio.h>#include<stdlib.h>void main(){  int *ptr = (int *)0;  *ptr = 100;}

3、访问只读的内存地址

#include<stdio.h>#include<stdlib.h>#include<string.h>void main(){  char *ptr = "test";  strcpy(ptr, "TEST");}

4、栈溢出

#include<stdio.h>#include<stdlib.h>void main(){  main();}

5、delete使用错误

delete只能删除new得来的内存，上面的p指向了新的内存，原先new来的内存已找不到了，内存泄漏。

上面释放了两次new来的内存。

下面是程序中的一个段错误实例：

上面的段错误是因为越界了。数组的边界没有确定好，此处是循环的数量错了。（还有一次是指针数组忘记分配内存了）

三、内存问题

内存问题始终是c++程序员需要去面对的问题，这也是c++语言的门槛较高的原因之一。通常我们会犯的内存问题大概有以下几种：
1.内存重复释放，出现double free时，通常是由于这种情况所致。
2.内存泄露，分配的内存忘了释放。
3.内存越界使用，使用了不该使用的内存。
4.使用了无效指针。
5.空指针，对一个空指针进行操作。

第四种情况，通常是指操作已释放的对象，如：
1.已释放对象，却再次操作该指针所指对象。
2.多线程中某一动态分配的对象同时被两个线程使用，一个线程释放了该对象，而另一线程继续对该对象进行操作。
重点探讨第三种情况，相对于另几种情况，这可以称得上是疑难杂症了（第四种情况也可以理解成内存越界使用）。

内存越界使用，这样的错误引起的问题存在极大的不确定性，有时大，有时小，有时可能不会对程序的运行产生影响，正是这种不易重现的错误，才是最致命的，一旦出错破坏性极大。
什么原因会造成内存越界使用呢？有以下几种情况，可供参考：
例1：
        char buf[32]= {0};
        for(int i=0;i<n; i++)// n < 32 or n > 32
        {
           buf[i] = 'x';
        }
例2:
        char buf[32]= {0};
        string str ="this is a test sting !!!!";
        sprintf(buf,"this is a test buf!string:%s", str.c_str()); //out of buffer space
例3:
        string str ="this is a test string!!!!";
        char buf[16]= {0};
        strcpy(buf,str.c_str()); //out of buffer space

当这样的代码一旦运行，错误就在所难免，会带来的后果也是不确定的，通常可能会造成如下后果：
1.破坏了堆中的内存分配信息数据，特别是动态分配的内存块的内存信息数据，因为操作系统在分配和释放内存块时需要访问该数据，一旦该数据被破坏，以下的几种情况都可能会出现。 
        *** glibcdetected *** free(): invalid pointer:
        *** glibcdetected *** malloc(): memory corruption:
        *** glibcdetected *** double free or corruption (out): 0x00000000005c18a0 ***
        *** glibcdetected *** corrupted double-linked list: 0x00000000005ab150***        
2.破坏了程序自己的其他对象的内存空间，这种破坏会影响程序执行的不正确性，当然也会诱发coredump，如破坏了指针数据。
3.破坏了空闲内存块，很幸运，这样不会产生什么问题，但谁知道什么时候不幸会降临呢？
通常，代码错误被激发也是偶然的，也就是说之前你的程序一直正常，可能由于你为类增加了两个成员变量，或者改变了某一部分代码，coredump就频繁发生，而你增加的代码绝不会有任何问题，这时你就应该考虑是否是某些内存被破坏了。
四、错误排查
保持好的编码习惯是杜绝错误的最好方式！排查的原则，首先是保证能重现错误，根据错误估计可能的环节，逐步裁减代码，缩小排查空间。
1、检查所有的内存操作函数，检查内存越界的可能。常用的内存操作函数：
sprintf strcpy strcat  memcpy memmove memset等，如果有用到自己编写的动态库的情况，要确保动态库的编译与程序编译的环境一致。

2、捕获段错误，针对段错误的信号调用 sigaction 注册一个处理函数就可以了。发生段错误时的函数调用关系体现在栈帧上，可以通过在信号处理函数中调用 backstrace 来获取栈帧信息。先输出堆栈信息，接下来，分析出错时的函数调用路径。

在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈。

int backtrace(void **buffer,int size) 

该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中，它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void*元素。函数返回值是实际获取的指针个数,最大不超过size大小

在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址

注意:某些编译器的优化选项对获取正确的调用堆栈有干扰，另外内联函数没有堆栈框架;删除框架指针也会导致无法正确解析堆栈内容。

char ** backtrace_symbols (void *const *buffer, int size) 

backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组，参数buffer应该是从backtrace函数获取的指针数组，size是该数组中的元素个数(backtrace的返回值)。

函数返回值是一个指向字符串数组的指针，它的大小同buffer相同。每个字符串包含了一个相对于buffer中对应元素的可打印信息，它包括函数名，函数的偏移地址和实际的返回地址。

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <execinfo.h>
#include <signal.h>

void dump(int signo)
{
     void *buffer[30] = {0};
     size_t size;
     char **strings = NULL;
     size_t i = 0;

     size = backtrace(buffer, 30);
     fprintf(stdout, "Obtained %zd stack frames.nm\n", size);
     strings = backtrace_symbols(buffer, size);
    if (strings == NULL)
     {
         perror("backtrace_symbols.");
         exit(EXIT_FAILURE);
     }
 
    for (i = 0; i < size; i++)
    {
        fprintf(stdout, "%s\n", strings[i]);
    }
   free(strings);
   strings = NULL;
   exit(0);
}

void func_c()
{
   *((volatile int *)0x0) = 0x9999;
}

void func_b()
{
    func_c();
}

void func_a()
{
    func_b();
}

int main(int argc, const char *argv[])
{
    if (signal(SIGSEGV, dump) == SIG_ERR)
       perror("can't catch SIGSEGV");
    func_a();
    return 0;
}

objdump是用查看目标文件或者可执行的目标文件的构成的GCC工具。

objdump -x obj 以某种分类信息的形式把目标文件的数据组织（被分为几大块）输出 <可查到该文件的所有动态库>   
objdump -t obj 输出目标文件的符号表()
objdump -h obj 输出目标文件的所有段概括()
objdump -j .text/.data -S obj 输出指定段的信息，大概就是反汇编源代码把
objdump -S obj C语言与汇编语言同时显示

或者使用下面的命令输出具体的行数：

3、不在用户自己编写的函数内的错误查找

动态链接库无非就是编译后的代码，里面有一些基本的段、符号信息。如果出错代码行在动态链接库内，那必然可以从动态链接库内找到出错时的代码行号。

因为进程挂掉时输出的地址，和动态链接库文件内的静态偏移地址根本就不是一回事。所以我们需要知道出错时，所输出的代码地址与动态链接库偏移地址之间的关系。

事实上，每一个进程都对应了一个 /proc/pid 目录，下面记载了诸多与该进程相关的信息，其中有一个maps文件，里面记录了各个动态链接库的加载地址。我们只需要根据所得到的出错地址，以及这个maps文件，就可以得出具体是哪一个库，相应的偏移地址是多少。

知道了对应的动态链接库和偏移地址后，我们进一步用 addr2line 将这个偏移地址翻译一下就可以了。

（可以在程序中加入输出语句或断点，因为出现段错误的时候就不会继续执行了）

dmesg可以在应用程序crash掉时，显示内核中保存的相关信息。可通过dmesg命令可以查看发生段错误的程序名称、引起段错误发生的内存地址、指令指针地址、堆栈指针地址、错误代码、错误原因等。

使用ldd命令查看二进制程序的共享链接库依赖，包括库的名称、起始地址，这样可以确定段错误到底是发生在了自己的程序中还是依赖的共享库中。

4、使用cout输出信息

这个是看似最简单但往往很多情况下十分有效的调试方式，也许可以说是程序员用的最多的调试方式。简单来说，就是在程序的重要代码附近加上像cout这类输出信息，这样可以跟踪并打印出段错误在代码中可能出现的位置。

为了方便使用这种方法，可以使用条件编译指令#ifdefDEBUG和#endif把printf函数包起来。这样在程序编译时，如果加上-DDEBUG参数就能查看调试信息；否则不加该参数就不会显示调试信息。

5、catchsegv命令

catchsegv命令专门用来扑获段错误，它通过动态加载器（ld-linux.so）的预加载机制（PRELOAD）把一个事先写好的库（/lib/libSegFault.so）加载上，用于捕捉断错误的出错信息。

五、一些注意事项

1、出现段错误时，首先应该想到段错误的定义，从它出发考虑引发错误的原因。

2、在使用指针时，定义了指针后记得初始化指针，在使用的时候记得判断是否为NULL。

3、在使用数组时，注意数组是否被初始化，数组下标是否越界，数组元素是否存在等。

4、在访问变量时，注意变量所占地址空间是否已经被程序释放掉。

5、在处理变量时，注意变量的格式控制是否合理等。