Question

如何分析Android的Log

Answer 1

　　首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

　　pid: 2102, tid: 2102,name: testapp >>>./testapp <<<

　　从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

　　接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

　　signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

　　signal11是Linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr
00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

　　再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

　　I/DEBUG ( 127):backtrace:

　　I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

　　I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

　　I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

　　I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

　　因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

　　#./arm-eabi-addr2line -f
-eout/target/product/hammerhead/symbols/system/bin/testapp0x0000045e

　　参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

　　memcpy
/home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

　　剩余三个地址翻译如下：

　　main
/home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

　　out_vformat
/home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

　　_start libgcc2.c:0

　　利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。