一、导读
backtrace中，一般都只有一些地址。但是利用addr2line这个工具，就可以找到对应的代码行。前提条件是可执行程序或者动态链接库编译的时候带-g选项。
具体来说，分两种情况：
-
如果关注的一行backtrace位于一个可执行文件中，那么直接
addr2line -e -
如果关注的backtrace位于一个动态链接库中，那么麻烦一些，因为动态链接库的基地址不是固定的。这个时候，首先要把进程的memory map找来。在linux下，进程的memory map可以在
/proc/文件中得到。然后在这个文件中找到动态链接库的基地址，然后将backtrace中的地址 - 动态链接库的基地址，得到偏移地址offset address, 最后/maps addr2line -e。
当然，用gdb也可以找出地址对应的代码行。不过相比addr2line，gdb需要将bug现象重现一遍，所以对于不好重现的bug，或是随机重现的bug来说，使用addr2line就可以直接从backtrace找到对应的代码行，不需要重现现象，比gdb使用起来更简单。
二、实践部分
1、获取程序的调用栈
在linux上的c/c 编程环境下，我们可以通过如下三个函数来获取程序的调用栈信息。
#include
/* store up to size return address of the current program state in
array and return the exact number of values stored. */
int backtrace(void **array, int size);
/* return names of functions from the backtrace list in array in a newly
malloc()ed memory block. */
char **backtrace_symbols(void *const *array, int size);
/* this function is similar to backtrace_symbols() but it writes the result
immediately to a file. */
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提供的接口从而导致发生段错误退出。它们的源程序分别如下：
/*
* add.c
*/
#include
#include
#include
int add1(int num)
{
int ret = 0x00;
int *ptemp = null;
*ptemp = 0x01; /* 这将导致一个段错误，致使程序崩溃退出 */
ret = num *ptemp;
return ret;
}
int add(int num)
{
int ret = 0x00;
ret = add1(num);
return ret;
}
/*
* dump.c
*/
#include
#include
#include
#include /* for signal */
#include /* for backtrace() */
#define backtrace_size 16
void dump(void)
{
int j, nptrs;
void *buffer[backtrace_size];
char **strings;
nptrs = backtrace(buffer, backtrace_size);
printf("backtrace() returned %d addresses\n", nptrs);
strings = backtrace_symbols(buffer, nptrs);
if (strings == null) {
perror("backtrace_symbols");
exit(exit_failure);
}
for (j = 0; j < nptrs; j )
printf(" [d] %s\n", j, strings[j]);
free(strings);
}
void signal_handler(int signo)
{
#if 0
char buff[64] = {0x00};
sprintf(buff,"cat /proc/%d/maps", getpid());
system((const char*) buff);
#endif
printf("\n=========>>>catch signal %d <<<=========\n", signo);
printf("dump stack start...\n");
dump();
printf("dump stack end...\n");
signal(signo, sig_dfl); /* 恢复信号默认处理 */
raise(signo); /* 重新发送信号 */
}
/*
* backtrace.c
*/
#include
#include
#include
#include /* for signal */
#include /* for backtrace() */
extern void dump(void);
extern void signal_handler(int signo);
extern int add(int num);
int main(int argc, char *argv[])
{
int sum = 0x00;
signal(sigsegv, signal_handler); /* 为sigsegv信号安装新的处理函数 */
sum = add(sum);
printf(" sum = %d \n", sum);
return 0x00;
}
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文件也打印出来，加入如下代码：
char buff[64] = {0x00};
sprintf(buff,"cat /proc/%d/maps", getpid());
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，由前面可知这个地址是正确的。
扩展：
通过在编译过程中生成so包的map文件，其中存放的是堆栈的各种信息，实际上除了生成map之外，还可以通过readelf -s 和nm两个命令来查询逻辑地址，实现对问题的定位。
例如：
其中libtest_lib,so对应的是libadd.so这个包，libtest_lib.so是我在自己电脑上打包起的名字。可以看出其实都是一样的地址。