段错误总结

https://blog.csdn.net/e_road_by_u/article/details/61415732

1、段错误是什么

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

2、段错误产生的缘由
一、访问不存在的内存地址
#include<stdio.h>
#include<stdlib.h>
void main()
{
  int *ptr = NULL;
  *ptr = 0;
}
二、访问系统保护的内存地址
#include<stdio.h>
#include<stdlib.h>
void main()
{
  int *ptr = (int *)0;
  *ptr = 100;
}
三、访问只读的内存地址
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
void main()
{
  char *ptr = "test";
  strcpy(ptr, "TEST");
}
四、栈溢出
#include<stdio.h>
#include<stdlib.h>
void main()
{
  main();
}
五、delete使用错误

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

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

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

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

3、内存问题

内存问题始终是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就频繁发生，而你增长的代码毫不会有任何问题，这时你就应该考虑是不是某些内存被破坏了。
4、错误排查
保持好的编码习惯是杜绝错误的最好方式！排查的原则，首先是保证能重现错误，根据错误估计可能的环节，逐步裁减代码，缩小排查空间。
一、检查全部的内存操做函数，检查内存越界的可能。经常使用的内存操做函数：
sprintf strcpy strcat  memcpy memmove memset等，若是有用到本身编写的动态库的状况，要确保动态库的编译与程序编译的环境一致。

二、捕获段错误，针对段错误的信号调用 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语言与汇编语言同时显示

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

三、不在用户本身编写的函数内的错误查找

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

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

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

知道了对应的动态连接库和偏移地址后，咱们进一步用 addr2line 将这个偏移地址翻译一下就能够了。

（能够在程序中加入输出语句或断点，由于出现段错误的时候就不会继续执行了）

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

使用ldd命令查看二进制程序的共享连接库依赖，包括库的名称、起始地址，这样能够肯定段错误究竟是发生在了本身的程序中仍是依赖的共享库中。

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

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

五、catchsegv命令

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

5、一些注意事项
一、出现段错误时，首先应该想到段错误的定义，从它出发考虑引起错误的缘由。

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

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

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

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