一次segfault错误的排查过程

                                                                                                    一次segfault错误的排查过程

正常运行了几年的程序忽然崩溃了，由于机器没有设置CORE文件，无法从CORE中取得错误信息，程序运行在centOS 7上， 本来对centOS用的也是不熟，只能边查资料边查问题。

首先、我需要确认程序是否真的崩溃了，还是别人误操作关闭了。如果程序真的崩溃了，会在系统中留下痕迹，我查了一下，在messages文件中发现了一条信息：

xxxxx.o[2374]: segfault at7f0ed0bfbf70 ip 00007f0edd646fe7 sp 00007f0ed3603978 error 4 inlibc-2.17.so[7f0edd514000+1b6000]

由上面信息看出，系统确实是崩溃了，发生了段错误。

查看messages需要root权限，用命令：cat /var/log/messages 就可以了，还有一个命令dmesg也可以查到上面的信息。

从上面的信息，我们可以得到以下信息：

1、从libc-2.17.so[7f0edd514000+1b6000]可以看出错误发生在libc上，libc在此程序中映射的内存基址为7f0edd514000，这个信息是个坏消息，这个so上的东西太多了；

2、segfault at和error 4这两条信息可以得出是内存读出错，4的意义如下，可以对照参考：

bit2:值为1表示是用户态程序内存访问越界，值为0表示是内核态程序内存访问越界
bit1: 值为1表示是写操作导致内存访问越界，值为0表示是读操作导致内存访问越界
bit0: 值为1表示没有足够的权限访问非法地址的内容，值为0表示访问的非法地址根本没有对应的页面，也就是无效地址

4正好为用户态内存读操作访问出界。

3、7f0ed0bfbf70，00007f0edd646fe7，00007f0ed3603978这三个值：第一个值为出错的地址，用处不大；第二个值为发生错误时指令的地址，这个值在有些错误时是错误的，下面会讲一下，第三个值为堆栈指针。

除了以上信息，就是六七万行的代码。感觉没有太大的指望。

C++段错误就几类，读写错误，这个主要是参数没有控制好，这种错误比较常见，我们经常把NULL指针、未初始化或非法值的指针传递给函数，从而引出此错误；指令地址出错，这类错误主要是由虚函数，回调函数引起，最常出现的是虚函数，由于虚函数保存在类变量中，如果不小心用了非安全函数，就可能把虚数指针覆盖掉，从而影响出现错误。但指令地址出错的情况相对参数出错来讲还是要少很多的，因为用到此功能的还是需要一定的水平的，不容易犯一些低级错误。

从上面分析的第二点来看，基本上属于读写错误，但从六七万行代码找出问题，可能性不大，只能缩小范围，我决定从上面提到的三点，找到出错的函数，然后再从代码中找出所有出错函数调用的地方来定位问题。由于错误指出出错的组件为libc，而且基本上是参数出现，所以发现错误的指令地址应该是可信的，我们可以根据指令地址查出是哪个函数。指令地址为：00007f0edd646fe7 ，libc指令的基地址为：7f0edd514000，可以根据这两个值计算一下该指令的相对地址为132FE7，下面我们需要找到相对代码段地址为132FE7的地方为什么函数。

开始我想得到反汇编代码，但这个组件代码太多，看不到头，于是我找了个取巧的办法，查看导出函数和基地址，结果所以还是很多，我就用132和133进行了一下过滤，得出以下信息

[root@localhostlib64]# objdump -tT libc-2.17.so | grep 132