Android Tombstone/Crash的log分析和定位(墓碑文件)

=====项目中遇到进程挂掉的问题，需要分析Tombstone，本文帮了大忙

http://blog.csdn.net/helldevil/article/details/6682211

9楼 adits 2013-04-22 16:20发表 [回复] [引用] [举报]

命令使用有误： 原文： addr2line -e -f libc.so 0001173c 应该是 addr2line -e libc.so -f 0001173c

===================================================================================================

有一句话叫做常在河边走，哪有不湿鞋。我们这些研究和开发Android的工程师正应了这句话，相必大家在调试的时候经常会遇到这么个东西吧

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'XXXXXXXXX'pid: 1658, tid: 13086  >>> system_server deassmble_libc.txt 反汇编下你的动态连接库文件，并且将它写入一个文件中。

   打开这个反汇编过后的重定向文件，在查询的时候输入1173c这个偏移地址，你会看到在茫茫人海中

  00011684 :    11684:       e92d4ff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}    11688:       e24dd01c        sub     sp, sp, #28     ; 0x1c    1168c:       e1a06001        mov     r6, r1    11690:       e1a08002        mov     r8, r2    11694:       e1a09003        mov     r9, r3    11698:       e3a04001        mov     r4, #1  ; 0x1    1169c:       e59f521c        ldr     r5, [pc, #540]  ; 118c0    116a0:       e58d000c        str     r0, [sp, #12]    116a4:       eb009a35        bl      37f80    116a8:       e59f2214        ldr     r2, [pc, #532]  ; 118c4    116ac:       e1a03000        mov     r3, r0    116b0:       e1a01004        mov     r1, r4    116b4:       e593c000        ldr     ip, [r3]    116b8:       e3a0003c        mov     r0, #60 ; 0x3c    116bc:       e08f3005        add     r3, pc, r5    116c0:       e7933002        ldr     r3, [r3, r2]    116c4:       e5834000        str     r4, [r3]    116c8:       e58dc010        str     ip, [sp, #16]    116cc:       eb009a3b        bl      37fc0    ...

   1173c:       ebffec2b        bl      c7f0 -->就是他了，对你成功了。

   ...

这个是ARM汇编，需要你翻译成对应的C函数去看，这里我就不做解释了，照着前面的步骤，

对上面中#15-->#00 一共16行慢慢去找，直到找到#00行的问题函数，其实，最后一个#00行的是最重要的（前面不找也行，但是可以多给你提供问题信息，和流程），因为他是第一目击者，也是Crash前的第一现场。所以找到这个函数很重要，假设我们最后经过万里长针发现#00的出错的地方是pXX->member挂了(MD，我经常遇到这种问题)。

那么你可以怀疑两个地方：

1 您的指针是空指针，但是现实与理想总是十万八千里，多数情况下很少出现，而且你分析代码后，也会对自己说怎么可能。绝大多数情况下，从我的经验来讲，很少会有空指针这种低级错误，但是不排除哪个2货出现了这么个问题。如果是这个问题，那么恭喜你，你很幸运。

2 还有就是怀疑越界和内存地址被挤占。就拿我以前的经验，指针不是空，但是根据汇编码看，是访问成员变量挂了，这个地址肯定是被占用了。

   针对第2种比较恶心的情况，就需要你看整个log的流程了，需要你看下主要的mainlog关于出现crash前的动作，看看是哪个孙子占用的，以最近原则为先，从下往上看，唉，说句实在话，李白的一句话可以形容整个过程:"蜀道难，难于上青天啊"。工作量大，而且要细致。我也没什么办法。。。

  还有一种情况，就是内存不够，导致了您的地址被挤占了，出现low memory, no more ...这样的语句，以及大量出现GC_FOR_MALLOC关于GC的东西(如果是少量的，可以忽略，大量的话)，呵呵表明你的某个进程在吞噬你的内存，存在内存泄漏。坑爹啊，这个问题，是最难查的，需要你花大量时间，去看内存的变化。一般看内存的情况是

cat /proc/meminfo

空闲内存=buffer+cache+free这三个字段，Active字段是已经使用的内存，Total不用说，是总的物理内存。(记住 free不高，并不代表你的内存空闲不高，海水不可斗量，需要看全了3个字段的总和才是空闲内存)

如果你想具体跟踪每个进程的内存使用情况，还是在/proc下面，对应了N多的数字文件，那个其实是PID号，进去后cat status可以看到

VMRSS XXXKB就是你当前进程的使用内存量，此外还有一些其他的内存数据，包括页啊等等。。。里面还有很多有用的数据，如果你想跟踪所有的进程的内存情况，推介大家可以看看linux ps命令的源码，看看人家是怎么在/proc下遍历进程，并且提取属性值的。

写个daemon，跟踪一段时间，记录下各进程内存的变化，然后就是通宵的分析。。。。

总之，这类问题，很难定位，也很难解决，需要花时间，精力去分析。但是如果你解了，那么相信所有人对你会刮目相看的。包括你的老板，量变引起质变，请记住。

我还在纠结中啊...分析ing

最后再说几句

stack:

#12 476e5eb8  476e5ed8       476e5ebc  476e5ed8       476e5ec0  00100000       476e5ec4  476e5ed8       476e5ec8  acaa4d38       476e5ecc  005ec9b0       476e5ed0  aca4e1a3  /system/lib/libdvm.so     476e5ed4  476e5ed8   #13 476e5ed8  005ec9b0       476e5edc  005ecae8       476e5ee0  476e5f00       476e5ee4  aca4e109  /system/lib/libdvm.so     476e5ee8  005ec9b0       476e5eec  afd11b98  /system/lib/libc.so #14 476e5ef0  476e5f00       476e5ef4  005ecae8       476e5ef8  45b29b84       476e5efc  afd11740  /system/lib/libc.so #15 476e5f00  476e5f00       476e5f04  005ecae8       476e5f08  00000009       476e5f0c  00000000       476e5f10  00000000       476e5f14  005ec9b0       476e5f18  00000000       476e5f1c  00000000  

红色的部分是基地址+偏移地址

比如afd +11740 这个afd你可以从prelink-linux-arm.map找到每个.so的基地址（比如 libc.so                 0xAFD00000 # [~2M]）11740可以从反汇编的文件中找到对应点，但是我不知道这些有什么用。  

希望这偏小文章能帮助到大家，大家共同进步，有好的方法也欢迎您一起分享。谢谢！

下面是一个老外的摘录早期存于google论坛的内存分析文章（现在没了），我是在他基础上，又加了一些分析和经验之谈，希望上帝保佑让我早点定位到问题。