利用dmesg和addr2line来重现bug

利用dmesg和addr2line来重现bug

有些时候，我们的程序crash了，但是我们没有保存core dump信息，这时如果我们想要知道程序在哪个位置出错，就不是那么容易了。下面有一种方法，可以大致判断出程序出错的大致位置。


1.用dmesg查找出错的代码段地址。
命令格式：

[plain] view plain copy print ?

1. dmesg | grep program_name  

其中program_name是可执行文件，比如：

[plain] view plain copy print ?

1. $ dmesg | grep test_prog  
2. [103936.227079] test_prog[29319]: segfault at 40078c ip 0000000000400634 sp 00007fffe54d4680 error 7 in test_prog[400000+1000]  

其中的ip后面的地址是程序出错处的地址。

2.用addr2line将地址解析成函数名。
紧接上面的例子：

[plain] view plain copy print ?

1. $ addr2line -e ./test_prog 0000000000400634 -f  
2. _Z9errorFuncv  
3. ??:0  

其中errorFunc即是出错的函数名，然后就可以找到相应的出错代码了。

使用 Addr2line 将函数地址解析为函数名

Addr2line 工具（它是标准的 GNU Binutils 中的一部分）是一个可以将指令的地址和可执行映像转换成文件名、函数名和源代码行数的工具。这种功能对于将跟踪地址转换成更有意义的内容来说简直是太棒了。

要了解这个过程是怎样工作的，我们可以试验一个简单的交互式的例子。（我直接从 shell 中进行操作，因为这是最简单地展示这个过程的方法，如清单 4 所示。）这个示例 C 文件（test.c）是通过 cat 一个简单的应用程序实现的（也就是说，将标准输出的文本重定向到一个文件中）。然后使用 gcc 来编译这个文件，它会传递一些特殊的选项。首先，要（使用 -Wl 选项）通知链接器生成一个映像文件，并（使用 -g 选项）通知编译器生成调试符号。最终生成可执行文件 test。得到新的可执行应用程序之后，您就可以使用 grep 工具在映像文件中查找 main 来寻找它的地址了。使用这个地址和 Addr2line 工具，就可以判断出函数名（main）、源文件（/home/mtj/test/test.c）以及它在源文件中的行号（4）。

在调用 Addr2line 工具时，要使用 -e 选项来指定可执行映像是 test。通过使用 -f 选项，可以告诉工具输出函数名。

清单 4. addr2line 的一个交互式例子

$ cat >> test.c
#include <stdio.h>
int main()
{
  printf("Hello World\n");
  return 0;
}
<ctld-d>
$ gcc -Wl,-Map=test.map -g -o test test.c
$ grep main test.map
	0x08048258		__libc_start_main@@GLIBC_2.0
	0x08048258		main
$ addr2line 0x08048258 -e test -f
main
/home/mtj/test/test.c:4
$

http://stackoverflow.com/questions/5314036/how-to-use-addr2line-in-android

Let's say that logcat show you the following crash log (this is from one of my projects):

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (   31): Build fingerprint: 'generic/sdk/generic:2.3/GRH55/79397:eng/test-keys'
I/DEBUG   (   31): pid: 378, tid: 386  >>> com.example.gltest <<<
I/DEBUG   (   31): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG   (   31):  r0 001dbdc0  r1 00000001  r2 00000000  r3 00000000
I/DEBUG   (   31):  r4 00000000  r5 40a40000  r6 4051a480  r7 42ddbee8
I/DEBUG   (   31):  r8 43661b24  r9 42ddbed0  10 42ddbebc  fp 41e462d8
I/DEBUG   (   31):  ip 00000001  sp 436619d0  lr 83a12f5d  pc 8383deb4  cpsr 20000010
I/DEBUG   (   31):          #00  pc 0003deb4  /data/data/com.example.gltest/lib/libnativemaprender.so
I/DEBUG   (   31):          #01  pc 00039b76  /data/data/com.example.gltest/lib/libnativemaprender.so
I/DEBUG   (   31):          #02  pc 00017d34  /system/lib/libdvm.so

Look at the last 3 lines; this is your callstack. 'pc' is the program counter, and the pc for stack frame #00 gives you the address where the crash occurred. This is the number to pass to addr2line.

I'm using NDK r5, so the executable I'm using is located at $NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin; make sure that is in your $PATH. The command to use looks like

arm-linux-androideabi-addr2line -C -f -e obj/local/armeabi/libXXX.so <address>

Or, for the case above:

arm-linux-androideabi-addr2line -C -f -e obj/local/armeabi/libnativemaprender.so 0003deb4

Which gives you the location of the crash.

Note:

• The -C flag is to demangle C++ code
• Use the .so file underobj/local/armeabi, since this is thenon-stripped version

Also, when using NDK r5 with a 2.3 AVD, it is actually possible to debug multithreaded code.