linux SIGSEGV信号内存访问错误 Segmentation fault

r囧r小猫 2021-08-24 12:12 991阅读 0赞

linux下程序对SIGSEGV信号的默认处理方式是产生coredump并终止程序，可以参考man 7 signal

> Signal     Value     Action   Comment  
> ──────────────────────────────────────────────────────────────────────  
> SIGHUP        1       Term    Hangup detected on controlling terminal  
>                               or death of controlling process  
> SIGINT        2       Term    Interrupt from keyboard  
> SIGQUIT       3       Core    Quit from keyboard  
> SIGILL        4       Core    Illegal Instruction  
> SIGABRT       6       Core    Abort signal from abort(3)  
> SIGFPE        8       Core    Floating point exception  
> SIGKILL       9       Term    Kill signal  
> SIGSEGV      11       Core    Invalid memory reference  
> SIGPIPE      13       Term    Broken pipe: write to pipe with no  
>                               readers  
> SIGALRM      14       Term    Timer signal from alarm(2)  
> SIGTERM      15       Term    Termination signal  
> SIGUSR1   30,10,16    Term    User-defined signal 1  
> SIGUSR2   31,12,17    Term    User-defined signal 2  
> SIGCHLD   20,17,18    Ign     Child stopped or terminated  
> SIGCONT   19,18,25    Cont    Continue if stopped  
> SIGSTOP   17,19,23    Stop    Stop process  
> SIGTSTP   18,20,24    Stop    Stop typed at terminal  
> SIGTTIN   21,21,26    Stop    Terminal input for background process  
> SIGTTOU   22,22,27    Stop    Terminal output for background process  
>

产生core这个动作的信号不止SIGSEGV这一个。通常程序中有对内存的Invalid reference就会产生SIGSEGV。

发生内存错误是件非常麻烦的事情。编译器不能自动发现这些错误，通常是在程序运行时才能捕捉到。而这些错误大多没有明显的症状，时隐时现，增加了改错的难度。有时用户怒气冲冲地把你找来，程序却没有发生任何问题，你一走，错误又发作了。 常见的内存错误及其对策如下：

\* 内存分配未成功，却使用了它。

编程新手常犯这种错误，因为他们没有意识到内存分配会不成功。常用解决办法是，在使用内存之前检查指针是否为NULL。如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行

检查。如果是用malloc或new来申请内存，应该用if(p==NULL) 或if(p!=NULL)进行防错处理。

\* 内存分配虽然成功，但是尚未初始化就引用它。

犯这种错误主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零，导致引用初值错误（例如数组）。 内存的缺省初值究竟是什么并没有统一的标准，尽管有些时候为零值，我们宁可信其无不可信其有。所以无论用何种方式创建数组，都别忘了赋初值，即便是赋零值也不可省略，不要嫌麻烦。

\* 内存分配成功并且已经初始化，但操作越过了内存的边界。

例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中，循环次数很容易搞错，导致数组操作越界。

\* 忘记了释放内存，造成内存泄露。

含有这种错误的函数每被调用一次就丢失一块内存。刚开始时系统的内存充足，你看不到错误。终有一次程序突然死掉，系统出现提示：内存耗尽。

动态内存的申请与释放必须配对，程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）。

\* 释放了内存却继续使用它。

有三种情况：

（1）程序中的对象调用关系过于复杂，实在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新设计数据结构，从根本上解决对象管理的混乱局面。

（2）函数的return语句写错了，注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。

（3）使用free或delete释放了内存后，没有将指针设置为NULL。导致产生“野指针”。

【规则1】用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。

【规则2】不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。

【规则3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。

【规则4】动态内存的申请与释放必须配对，防止内存泄漏。

【规则5】用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。

分析段错误的方法：

1.直接使用gdb

如果是容易重现的SIGSEGV直接gdb挂着运行，产生SIGSEGV时gdb会停止并打印提示，这时直接敲入命令bt查看程序此时的函数调用栈帧就可以定位到是哪个函数在什么样的调用情况下出现段错误。

2.使用core文件+gdb

在程序收到SIGSEGV时会产生coredump，core文件就是异常进程在发生异常的那一个时刻的进程内存上下文和cpu寄存器的信息。

首先，设置core文件大小 ulimit -c XXXX，XXXX就是允许产生的core文件大小，通常设置为unlimited，不限定大小

然后，运行程序直至产生core文件，名字一般是core.xxx，xxx为程序进程号，不同发行版本可能有不同的命名规则

然后，运行gdb,敲入命令 core-file corefile-name,再bt即可

3.注册SIGSEGV信号处理函数，在处理函数里面使用一些堆栈回溯的函数打印栈帧信息。

A.使用glibc带的函数backtrace backtrace\_symbols backtrace\_symbols\_fd打印

void SigSegv_handler(int signo)
           {
               int j, nptrs;
               void *buffer[BT_BUF_SIZE];
               char **strings;
     
               nptrs = backtrace(buffer, BT_BUF_SIZE);
               printf("backtrace() returned %d addresses\n", nptrs);
     
               /* The call backtrace_symbols_fd(buffer, nptrs, STDOUT_FILENO)
                  would produce similar output to the following: */
     
               strings = backtrace_symbols(buffer, nptrs);
               if (strings == NULL) {
                   perror("backtrace_symbols");
                   exit(EXIT_FAILURE);
               }
     
               for (j = 0; j < nptrs; j++)
                   printf("%s\n", strings[j]);
     
               free(strings);
    　　　　　　 exit(-1);
           }

backtrace\_symbols 和backtrace\_symbols\_fd不同在于后者将打印输入到一个fd指定的文件里面。

它有一定的限制：

> These functions make some assumptions about how a function's return address is stored on the stack.  Note the following:  
> 这些函数对函数的返回地址如何存储在堆栈上做了一些假设。请注意以下几点：  
> \*  Omission of the frame pointers (as implied by any of gcc(1)'s nonzero optimization levels) may cause these assumptions to be violated.  
> 省略帧指针（如gcc(1)的任何非0优化级别所暗示的）可能会违反这些假设。  
>    
> \*  Inlined functions do not have stack frames.  
> 内联函数没有堆栈帧。  
>    
> \*  Tail-call optimization causes one stack frame to replace another.  
> 尾部调用优化导致一个堆栈帧替换另一个堆栈帧。  
>    
> The symbol names may be unavailable without the use of special linker options.  For systems using the GNU linker, it is necessary to use the -rdynamic linker option.  Note that names of "static" functions are not exposed, and won't be available in the backtrace.  
> 如果不适用特殊的连接器选项，符号名可能不可用。对于使用GNU连接器的系统，有必要使用-rdynamic链接器选项。注意，“静态”函数的名称没有公开，并且在回溯中不可用。  
>

对优化的程序可能失效

对inline函数失效

对static函数仅能打印函数地址

对tail-call优化的函数失效

编译时需要加入 -rdynamic