文档章节

在Linux中如何利用backtrace信息解决程序崩溃的问题

shzwork
 shzwork
发布于 07/30 18:11
字数 3082
阅读 24
收藏 0

一、导读

在程序调试过程中如果遇到程序崩溃死机的情况下我们通常多是通过出问题时的栈信息来找到出错的地方,这一点我们在调试一些高级编程语言程序的时候会深有体会,它们通常在出问题时会主动把出问题时的调用栈信息打印出来,比如我们在eclipse中调试java程序时。

当这些换到Linux上的C/C++环境时情况将变的稍微复杂一些,通常在这种情况下是通过拿到出问题时产生的core文件然后再利用gdb调试来看到出错时的程序栈信息,这是再好不过的了,但当某些特殊的情况如不正确的系统设置或文件系统出现问题时导致我们没有拿到core文件那我们还有补救的办法吗?本文将介绍在程序中安排当出现崩溃退出时把当前调用栈通过终端打印出来并定位问题的方法。

二、输出程序的调用栈

1、获取程序的调用栈

在Linux上的C/C++编程环境下,我们可以通过如下三个函数来获取程序的调用栈信息。

 
  1. #include <execinfo.h>

  2.  
  3. /* Store up to SIZE return address of the current program state in

  4. ARRAY and return the exact number of values stored. */

  5. int backtrace(void **array, int size);

  6.  
  7. /* Return names of functions from the backtrace list in ARRAY in a newly

  8. malloc()ed memory block. */

  9. char **backtrace_symbols(void *const *array, int size);

  10.  
  11. /* This function is similar to backtrace_symbols() but it writes the result

  12. immediately to a file. */

  13. void backtrace_symbols_fd(void *const *array, int size, int fd);

它们由GNU C Library提供,关于它们更详细的介绍可参考Linux Programmer’s Manual中关于backtrack相关函数的介绍。

使用它们的时候有一下几点需要我们注意的地方:

  • backtrace的实现依赖于栈指针(fp寄存器),在gcc编译过程中任何非零的优化等级(-On参数)或加入了栈指针优化参数-fomit-frame-pointer后多将不能正确得到程序栈信息;
  • backtrace_symbols的实现需要符号名称的支持,在gcc编译过程中需要加入-rdynamic参数;
  • 内联函数没有栈帧,它在编译过程中被展开在调用的位置;
  • 尾调用优化(Tail-call Optimization)将复用当前函数栈,而不再生成新的函数栈,这将导致栈信息不能正确被获取。

2、捕获系统异常信号输出调用栈

当程序出现异常时通常伴随着会收到一个由内核发过来的异常信号,如当对内存出现非法访问时将收到段错误信号SIGSEGV,然后才退出。利用这一点,当我们在收到异常信号后将程序的调用栈进行输出,它通常是利用signal()函数,关于系统信号的

三、从backtrace信息分析定位问题

1、测试程序

为了更好的说明和分析问题,我这里将举例一个小程序,它有三个文件组成分别是backtrace.c、dump.c、add.c,其中add.c提供了对一个数值进行加一的方法,我们在它的执行过程中故意使用了一个空指针并为其赋值,这样人为的造成段错误的发生;dump.c中主要用于输出backtrace信息,backtrace.c则包含了我们的man函数,它会先注册段错误信号的处理函数然后去调用add.c提供的接口从而导致发生段错误退出。它们的源程序分别如下:

 

[cpp] view plain copy

  1. /* 
  2.  *   add.c 
  3.  */  
  4. #include <stdio.h>  
  5. #include <stdlib.h>  
  6. #include <unistd.h>  
  7.   
  8. int add1(int num)  
  9. {  
  10.     int ret = 0x00;  
  11.     int *pTemp = NULL;  
  12.       
  13.     *pTemp = 0x01;  /* 这将导致一个段错误,致使程序崩溃退出 */  
  14.       
  15.     ret = num + *pTemp;  
  16.       
  17.     return ret;  
  18. }  
  19.   
  20. int add(int num)  
  21. {  
  22.     int ret = 0x00;  
  23.   
  24.     ret = add1(num);  
  25.       
  26.     return ret;  
  27. }  

 

 

[cpp] view plain copy

  1. /* 
  2.  *   dump.c 
  3.  */  
  4. #include <stdio.h>  
  5. #include <stdlib.h>  
  6. #include <unistd.h>  
  7. #include <signal.h>       /* for signal */  
  8. #include <execinfo.h>     /* for backtrace() */  
  9.   
  10. #define BACKTRACE_SIZE   16  
  11.   
  12. void dump(void)  
  13. {  
  14.     int j, nptrs;  
  15.     void *buffer[BACKTRACE_SIZE];  
  16.     char **strings;  
  17.       
  18.     nptrs = backtrace(buffer, BACKTRACE_SIZE);  
  19.       
  20.     printf("backtrace() returned %d addresses\n", nptrs);  
  21.   
  22.     strings = backtrace_symbols(buffer, nptrs);  
  23.     if (strings == NULL) {  
  24.         perror("backtrace_symbols");  
  25.         exit(EXIT_FAILURE);  
  26.     }  
  27.   
  28.     for (j = 0; j < nptrs; j++)  
  29.         printf("  [%02d] %s\n", j, strings[j]);  
  30.   
  31.     free(strings);  
  32. }  
  33.   
  34. void signal_handler(int signo)  
  35. {  
  36.       
  37. #if 0     
  38.     char buff[64] = {0x00};  
  39.           
  40.     sprintf(buff,"cat /proc/%d/maps", getpid());  
  41.           
  42.     system((const char*) buff);  
  43. #endif    
  44.   
  45.     printf("\n=========>>>catch signal %d <<<=========\n", signo);  
  46.       
  47.     printf("Dump stack start...\n");  
  48.     dump();  
  49.     printf("Dump stack end...\n");  
  50.   
  51.     signal(signo, SIG_DFL); /* 恢复信号默认处理 */  
  52.     raise(signo);           /* 重新发送信号 */  
  53. }  

 

 

[cpp] view plain copy

  1. /* 
  2.  *   backtrace.c 
  3.  */  
  4. #include <stdio.h>  
  5. #include <stdlib.h>  
  6. #include <unistd.h>  
  7. #include <signal.h>       /* for signal */  
  8. #include <execinfo.h>     /* for backtrace() */  
  9.   
  10. extern void dump(void);  
  11. extern void signal_handler(int signo);  
  12. extern int add(int num);  
  13.   
  14. int main(int argc, char *argv[])  
  15. {  
  16.     int sum = 0x00;  
  17.       
  18.     signal(SIGSEGV, signal_handler);  /* 为SIGSEGV信号安装新的处理函数 */  
  19.       
  20.     sum = add(sum);  
  21.       
  22.     printf(" sum = %d \n", sum);  
  23.       
  24.     return 0x00;  
  25. }  

 

2、静态链接情况下的错误信息分析定位

我们首先将用最基本的编译方式将他们编译成一个可执行文件并执行,如下:

 

zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ gcc -g -rdynamic backtrace.c add.c dump.c -o backtrace
zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ ./backtrace   
=========>>>catch signal 11 <<<=========
Dump stack start...
backtrace() returned 8 addresses
  [00] ./backtrace(dump+0x1f) [0x400a9b]
  [01] ./backtrace(signal_handler+0x31) [0x400b63]
  [02] /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7f86afc7e150]
  [03] ./backtrace(add1+0x1a) [0x400a3e]
  [04] ./backtrace(add+0x1c) [0x400a71]
  [05] ./backtrace(main+0x2f) [0x400a03]
  [06] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f86afc6976d]
  [07] ./backtrace() [0x400919]
Dump stack end...
段错误 (核心已转储)

 

由此可见在调用完函数add1后就开始调用段错误信号处理函数了,所以问题是出在函数add1中。这似乎还不够,更准确的位置应该是在地址0x400a3e处,但这到底是哪一行呢,我们使用addr2line命令来得到,执行如下:

 

zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ addr2line -e backtrace 0x400a3e
/home/share/work/backtrace/add.c:13

 

2、动态链接情况下的错误信息分析定位

然而我们通常调试的程序往往没有这么简单,通常会加载用到各种各样的动态链接库。如果错误是发生在动态链接库中那么处理将变得困难一些。下面我们将上述程序中的add.c编译成动态链接库libadd.so,然后再编译执行backtrace看会得到什么结果呢。

 

/* 编译生成libadd.so */
gcc -g -rdynamic add.c -fPIC -shared -o libadd.so

/* 编译生成backtrace可执行文件 */
gcc -g -rdynamic backtrace.c dump.c -L. -ladd -Wl,-rpath=. -o backtrace

 

其中参数 -L. -ladd为编译时链接当前目录的libadd.so;参数-Wl,-rpath=.为指定程序执行时动态链接库搜索路径为当前目录,否则会出现执行找不到libadd.so的错误。然后执行backtrace程序结果如下:

 

zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ ./backtrace
=========>>>catch signal 11 <<<=========
Dump stack start...
backtrace() returned 8 addresses
  [00] ./backtrace(dump+0x1f) [0x400a53]
  [01] ./backtrace(signal_handler+0x31) [0x400b1b]
  [02] /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7f8583672150]
  [03] ./libadd.so(add1+0x1a) [0x7f85839fa5c6]
  [04] ./libadd.so(add+0x1c) [0x7f85839fa5f9]
  [05] ./backtrace(main+0x2f) [0x400a13]
  [06] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f858365d76d]
  [07] ./backtrace() [0x400929]
Dump stack end...
段错误 (核心已转储)

 

此时我们再用前面的方法将得不到任何信息,如下:

 

zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ addr2line -e libadd.so 0x7f85839fa5c6
??:0

 

这是为什么呢?

出现这种情况是由于动态链接库是程序运行时动态加载的而其加载地址也是每次可能多不一样的,可见0x7f85839fa5c6是一个非常大的地址,和能得到正常信息的地址如0x400a13相差甚远,其也不是一个实际的物理地址(用户空间的程序无法直接访问物理地址),而是经过MMU(内存管理单元)映射过的。

有上面的认识后那我们就只需要得到此次libadd.so的加载地址然后用0x7f85839fa5c6这个地址减去libadd.so的加载地址得到的结果再利用addr2line命令就可以正确的得到出错的地方;另外我们注意到(add1+0x1a)其实也是在描述出错的地方,这里表示的是发生在符号add1偏移0x1a处的地方,也就是说如果我们能得到符号add1也就是函数add1在程序中的入口地址再加上偏移量0x1a也能得到正常的出错地址。

我们先利用第一种方法即试图得到libadd.so的加载地址来解决这个问题。我们可以通过查看进程的maps文件来了解进程的内存使用情况和动态链接库的加载情况,所以我们在打印栈信息前再把进程的maps文件也打印出来,加入如下代码:

 

[cpp] view plain copy

  1. char buff[64] = {0x00};  
  2.       
  3. sprintf(buff,"cat /proc/%d/maps", getpid());  
  4.       
  5. system((const char*) buff);  

 

然后编译执行得到如下结果(打印比较多这里摘取关键部分):

 

....................................................
7f0962fb3000-7f0962fb4000 r-xp 00000000 08:01 2895572                    /home/share/work/backtrace/libadd.so
7f0962fb4000-7f09631b3000 ---p 00001000 08:01 2895572                    /home/share/work/backtrace/libadd.so
7f09631b3000-7f09631b4000 r--p 00000000 08:01 2895572                    /home/share/work/backtrace/libadd.so
7f09631b4000-7f09631b5000 rw-p 00001000 08:01 2895572                    /home/share/work/backtrace/libadd.so
.....................................................
=========>>>catch signal 11 <<<=========
Dump stack start...
backtrace() returned 8 addresses
  [00] ./backtrace(dump+0x1f) [0x400b7f]
  [01] ./backtrace(signal_handler+0x83) [0x400c99]
  [02] /lib/x86_64-linux-gnu/libc.so.6(+0x36150) [0x7f0962c2b150]
  [03] ./libadd.so(add1+0x1a) [0x7f0962fb35c6]
  [04] ./libadd.so(add+0x1c) [0x7f0962fb35f9]
  [05] ./backtrace(main+0x2f) [0x400b53]
  [06] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f0962c1676d]
  [07] ./backtrace() [0x400a69]
Dump stack end...
段错误 (核心已转储)

 

Maps信息第一项表示的为地址范围如第一条记录中的7f0962fb3000-7f0962fb4000,第二项r-xp分别表示只读、可执行、私有的,由此可知这里存放的为libadd.so的.text段即代码段,后面的栈信息0x7f0962fb35c6也正好是落在了这个区间。所有我们正确的地址应为0x7f0962fb35c6 - 7f0962fb3000 = 0x5c6,将这个地址利用addr2line命令得到如下结果:

 

zoulm@zoulm-VirtualBox:/home/share/work/backtrace$ addr2line -e libadd.so 0x5c6
/home/share/work/backtrace/add.c:13

 

可见也得到了正确的出错行号。

接下来我们再用提到的第二种方法即想办法得到函数add的入口地址再上偏移量来得到正确的地址。要得到一个函数的入口地址我们多种途径和方法,比如生成查看程序的map文件;使用gcc的nm、readelif等命令直接对libadd.so分析等。在这里我们只介绍生成查看程序的map文件的方法,其他方法可通过查看gcc手册和google找到。

1)利用gcc编译生成的map文件,用如下命令我们将编译生成libadd.so对应的map文件如下:

 

gcc -g -rdynamic add.c -fPIC -shared -o libadd.so -Wl,-Map,add.map

 

Map文件中将包含关于libadd.so的丰富信息,我们搜索函数名add1就可以找到其在.text段的地址如下:

 

................................... 
.text          0x00000000000005ac       0x55 /tmp/ccCP0hNf.o
                0x00000000000005ac                add1
                0x00000000000005dd                add
...................................

 

由此可知我们的add1的地址为0x5ac,然后加上偏移地址0x1a即0x5ac + 0x1a = 0x5c6,由前面可知这个地址是正确的。

四、最后再说几句

  • 通过addr2line命令,我们只需要想办法找出程序出错时的地址我们即可定位错误,这也就是加了调试信息的程序运行地址和源程序有着对应关系(gdb调试时可体会到);
  • 通过前面的叙述我们发现不管是定位发生在可执行程序中或动态链接库中的错误我们多可以利用找出符号的入口地址加上偏移量的方法来正确定位出错的地址(注意在C++中为了支持函数重载函数名通常多是做了混淆);
  • 以上实验全部是在x86的ubuntu平台下进行的,当转换到嵌入式Linux平台时只需将所有的gcc命令多要使用对应的交叉编译器的gcc命令,通常是在命令前多了个前缀,如arm-none-linux-gnueabi-addr2line,其他命令以此类推;
  • 利用程序运行时地址定位源程序位置的思想不管是在调试windows下或其他操作系统下的程序多适用,在MCU下无操作系统的情况下也同样适用,只是会因为平台和编译器的不同所使用的方法和手段会有所不同。

本文转载自:https://blog.csdn.net/gongmin856/article/details/79192259

shzwork
粉丝 13
博文 746
码字总数 10605
作品 0
厦门
私信 提问
利用系统提供的崩溃日志解Native层Bug

对Android开发者来讲,尤其是使用NDK编写Native层代码的开发者,在编码过程中通常会碰到各种各样的问题。追踪问题的方式有很多,除了在代码中添加日志,来观察程序运行过程中产生的异常外,对...

shzwork
03/26
53
0
如何定位Android NDK开发中遇到的错误

正式开始这个话题之前,先简单介绍一下什么是NDK和JNI,部分内容来自网络 Android NDK是什么,为什么我们要用NDK? Android NDK 是在SDK前面又加上了“原生”二字,即Native Development Ki...

糊涂熊
2014/12/16
14.7K
2
如何定位Android NDK开发中遇到的错误

正式开始这个话题之前,先简单介绍一下什么是NDK和JNI,部分内容来自网络 Android NDK是什么,为什么我们要用NDK? Android NDK 是在SDK前面又加上了“原生”二字,即Native Development Ki...

糊涂熊
2014/12/16
16
0
Linux使用信号量监控程序异常退出

1.何为黑匣子程序及其必要性 飞机上面的黑匣子用于飞机失事后对事故的时候调查,同理,程序的黑匣子用于程序崩溃后对崩溃原因进程定位。其实Linux提供的core dump机制就是一种黑匣子(core文...

满小茂
2016/06/16
2.8K
0
用 coredumpctl 更好地记录 bug

一个不幸的事实是,所有的软件都有 bug,一些 bug 会导致系统崩溃。当它出现的时候,它经常会在磁盘上留下一个被称为“核心转储core dump”的数据文件。该文件包含有关系统崩溃时的相关数据,...

作者: Paul W. Frields
2017/11/28
0
0

没有更多内容

加载失败,请刷新页面

加载更多

查看线上日志常用命令

cat 命令(文本输出命令) 通常查找出错误日志 cat error.log | grep 'nick' , 这时候我们要输出当前这个日志的前后几行: 显示file文件里匹配nick那行以及上下5行 cat error.log | grep -C ...

xiaolyuh
29分钟前
5
0
六、Java设计模式之工厂方法

工厂方法定义: 定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行 类型:创建型 工厂方法-使用场景: 创建对象需要大量重复的代码 ...

东风破2019
36分钟前
5
0
win服务器管理遇到的一系列问题记录

有些小伙伴在使用iis7远程桌面管理工具的时候总是会遇到一系列的问题,下面就是为大家介绍一下服务器日常管理过程中出现的问题及我的解决办法和心得。希望能帮到大家。   拒绝服务器重新启...

1717197346
43分钟前
6
0
flutter 剪切板 复制粘贴

复制粘贴功能 import 'package:flutter/services.dart'; Clipboard.setData(ClipboardData(text:_text));Clipboard.getData;...

zdglf
46分钟前
4
0
如何保证消息的可靠性传输?或者说,如何处理消息丢失的问题?

面试题 如何保证消息的可靠性传输?或者说,如何处理消息丢失的问题? 面试官心理分析 这个是肯定的,用 MQ 有个基本原则,就是数据不能多一条,也不能少一条,不能多,就是前面说的重复消费...

米兜
46分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部