首先我们先来搞清楚什么会导致段错误(Segmentation fault)。段错误是指硬件设备MMU(内存管理单元)发现访问了一个非法的虚拟地址,通知操作系统内核给进程发送11号信号(SIGSEGV信号),导致进程异常终止。

一般来说,段错误是由以下几个原因导致的:

  • 解引用空指针
  • 访问不可访问的内存空间(如内核空间)
  • 访问不存在的内存地址
  • 试图写一个只读内存空间(如代码段)
  • 栈溢出(函数递归调用太深)
  • 使用未初始化的指针(定义时没有初始化或者已经回收)

搞清楚缘由后,我们就可以下手来处理了,这里我们以一个空指针引用为例:

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

转储核心文件

这里需要说明的是我们可以通过以下命令来控制是否自动转储核心文件(在服务器上用的较多)

#开启无限制转储
ulimit -c unlimited;
#关闭转储
ulimit -c 0;
#num为最多转储的核心文件数目
ulimit -c (num);

上述选项开启后,应用程序在运行时出现吐核,就会产生一个coredump文件(例如:core.21922),该文件会产生在对应应用出错的位置。
然后我们就可以,利用一下命令对其进行调试分析。

gdb test(可执行文件名) core.21922(吐出的转储文件)

一般分析过程

可以看出这里我们对空指针进行了赋值,接下来我们对其进行编译运行:

gcc -g test.c -o test
gdb test

进入gdb交互界面后我们可以执行run命令开始运行
在这里插入图片描述
可以看见在运行之后,程序在第4行停下出现段错误,下面的红框表示我们缺少展示详细调试信息的包,详情请查看:调试信息包的安装

这里我说一下一般解决问题的思路:

  • 进入GDB运行程序直到程序出错
  • 查看出错的代码段的行数
  • 对出现问题行的前一行设置断点(break [行数])并监视该代码段涉及的变量(watch [变量名])
  • 如果涉及递归调用,在运行过程中需要经常查看堆栈列表(bt/backtrace)避免堆栈溢出
  • 然后就可以开始运行,当到达断点行或监视变量发生改变时就会停下来,这时可以展示被监视的变量(dispaly [变量名]),这样然后再单步执行(step),查看变量是否按照预期在变化

一般通过上述方式,只要有时间,基本都能找出问题的所在。如果上述方式仍然无法发现问题可能就是操作系统层面的问题了,只有使用IDA对程序进行反汇编后结合不同的平台,对每条指令进行详细地分析了。

关于GDB调试工具的更多使用方式可以参照:GDB使用教程

调试信息包的安装

从程序中的提示中可以看出,由于缺乏相应的调试信息包,无法输出更多的调试信息。于是按照系统提示,执行以下命令后:

debuginfo-install glibc-2.17-292.el7.x86_64

在这里插入图片描述
你会发现其下载速度感人,由于我这里使用的是Centos 7.6.1810,我就到国内镜像源站点(阿里云镜像源清华镜像源)去找寻对应的安装包,结果发现没有x86架构的了。在这里附上我打好包的百度云链接:glibc-2.17-292.el7.x86_64 提取码:0s8c

其他版本的,请自行到镜像源站点搜索下载!

压缩包下载解压以后,按照如下顺序(存在依赖关系)安装即可:

rpm -ivh glibc-debuginfo-common-2.17-292.el7.x86_64.rpm
rpm -ivh glibc-debuginfo-2.17-292.el7.x86_64.rpm
rpm -ivh nss-softokn-debuginfo
rpm -ivh yum-plugin-auto-update-debug-info-1.1.31-52.el7.noarch.rpm
Logo

为开发者提供学习成长、分享交流、生态实践、资源工具等服务,帮助开发者快速成长。

更多推荐