android 底层log分析 内存及backtrace tombstone/crash
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086 >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
r0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654d
r4 64696f72 r5 00000406 r6 00974130 r7 40d14008
r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8
ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030
d0 4040000040000000 d1 0000004200000003
d2 4e72cd924285e370 d3 00e81fe04b1b64d8
d4 3fbc71c7009b64d8 d5 3fe999999999999a
d6 4010000000000000 d7 4000000000000000
d8 4000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
scr 80000012
#00 pc 000108d8 /system/lib/libc.so
#01 pc 0003724c /system/lib/libxvi020.so
#02 pc 0000ce02 /system/lib/libxvi020.so
#03 pc 0000d672 /system/lib/libxvi020.so
#04 pc 00010cce /system/lib/libxvi020.so
#05 pc 00004432 /system/lib/libwimax_jni.so
#06 pc 00011e74 /system/lib/libdvm.so
#07 pc 0004354a /system/lib/libdvm.so
#08 pc 00017088 /system/lib/libdvm.so
#09 pc 0001c210 /system/lib/libdvm.so
#10 pc 0001b0f8 /system/lib/libdvm.so
#11 pc 00059c24 /system/lib/libdvm.so
#12 pc 00059e3c /system/lib/libdvm.so
#13 pc 0004e19e /system/lib/libdvm.so
#14 pc 00011b94 /system/lib/libc.so
#15 pc 0001173c /system/lib/libc.so
code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e
ad115eac 4605b570 447c4c0a f7f44620 e006edc8
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70
ad115edc 00017332 00017312 2100b51f 46682210
code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004
afd110f8 e2055a02 e1a00005 e3851001 ebffed92
afd11108 e3500000 13856002 1a000001 ea000009
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92
afd11128 e1a01005 e1550000 e1a02006 e3a03000
stack:
4b857b10 40e43be8
4b857b14 00857280
4b857b18 00000000
4b857b1c 034e8968
4b857b20 ad118ce9 /system/lib/libnativehelper.so
4b857b24 00000002
4b857b28 00000406
.....
初一看到直接崩溃,我的个妈,这么一大坨,啥玩意啊,完全搞不懂,没有头绪撒。这NND Android出了问题,冒出这么大堆的地址,搞毛呢。
其实, 我可以很负责任的告诉你,兄弟这么多其实我也看不懂,在我眼里除了红色和蓝色的地方,其他全是废话。因为除了这两个地方意外,其他的我确实看不懂,一堆线性地址,外加寄存器,跟火星文一样。
算了,废话不多少,直接分析:
1 红色的地方,是让我们确认问题到底发生在那个线程中,是主线程还是子线程,这个的判断依据是:如果PID和TID相同,恭喜你问题出在父亲这边,看样子问题还比较好办。如果PID和TID不相同,那么您悲剧了,问题出在子线程中。根据我的经验,100的tombstone中,问题出现在父线程的概率,我还从来没发现,尤其是什么system_server, zygote这些,基本都是儿子的问题。唉,谁叫父亲英雄,儿狗熊呢。。。
2 确认了问题的基本点,下面就是开始看蓝色的部分了。
这个蓝色不分是从#00-->#XX 表面上看是从上往下的增长,其实坑爹啊,它所显示的程序的执行流程,恰恰是从下往上的也就是实际的执行顺序是#XX-->#00。
所以一开始我们的目的是分析第一个出现问题的动态连接库
#15 pc 0001173c /system/lib/libc.so
a 首先按图索骥,找到你的目标,libc.so这个一般会在你编译完的目标目录下,也就是out/target/product/your_pro/system/lib这个目录下。
b 一般你如果用的是还像样的linux系统,会有个地址解析的命令addr2line,负责解析动态连接库的(如果你是悲剧,没有这个命令,那好吧, google早就预料到会有象你这样的悲剧人,他们在prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-addr2line,给您准备了个,咋就用这个吧,功能一样,没啥区别)
addr2line -e -f libc.so 0001173c 红色是你的目标库,绿色是你出问题的地址,看看#15这行
结果出现:??pthread_create
??:0
恩,好了问题应该出在这个函数中,认为大功告成了?我,呸,还早呢。这个只是告诉你函数入口,至于具体执行到这个函数的哪个地方挂了,还得再看。
c 找到了是哪个部分出了问题,下面就是开启显微镜,看看谁搞的东东。
使用objdump -S -D libc.so > deassmble_libc.txt 反汇编下你的动态连接库文件,并且将它写入一个文件中。
打开这个反汇编过后的重定向文件,在查询的时候输入1173c这个偏移地址,你会看到在茫茫人海中
00011684 <pthread_create>:
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 <pthread_create+0x23c>
116a0: e58d000c str r0, [sp, #12]
116a4: eb009a35 bl 37f80 <strncmp+0x20>
116a8: e59f2214 ldr r2, [pc, #532] ; 118c4 <pthread_create+0x240>
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 <strncmp+0x60>
...
1173c: ebffec2b bl c7f0 <__pthread_clone>-->就是他了,对你成功了。
...
这个是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可以从反汇编的文件中找到对应点,但是我不知道这些有什么用。
转自:http://blog.csdn.net/helldevil/article/details/6682211/
An Android crash in C/C++ code often generates some crash log which looks like the following. They can be seen either with "adb logcat" or found in one of the tombstones under /data/tombstones. This article briefly explains the structure of the log, how to read it, and how to translate the addresses into symbols with the stack tool.
The basic items in the log is explained below. The first is the build information in the system property "ro.build.fingerprint"
I/DEBUG ( 730): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 730): Build fingerprint: 'generic/generic/generic/:1.5/...'
Then, it shows the process ID number (pid) and the thread id (tid). Knowing the PID, one can find its information with /proc/<pid> (of course, before the crash happens). In this example, the PID and TID are the same. However, if the crash happens in a child thread, the thread ID tid will be different from pid. The child thread itself is also a process in Linux (having its task_struct). The difference from a child process created by fork is that it shares address space and other data with the parent process.
I/DEBUG ( 730): pid: 876, tid: 876 >>> /system/bin/mediaserver <<<
The following shows the signal which caused the process to abort, in this case, it's a segmentation fault. This is followed by the register values.
I/DEBUG ( 730): signal 11 (SIGSEGV), fault addr 00000010
I/DEBUG ( 730): r0 00000000 r1 00016618 r2 80248f78 r3 00000000
I/DEBUG ( 730): r4 80248f78 r5 0000d330 r6 80248f78 r7 beaf9974
I/DEBUG ( 730): r8 00000000 r9 00000000 10 00000000 fp 00000000
I/DEBUG ( 730): ip afd020c8 sp beaf98d8 lr 8021edcd pc 8021c630 cpsr a0000030
This is the call stack trace. #00 is the depth of the stack pointer. The "pc <addr>" is the PC address in the stack. Sometimes, the "lr" link register containing the return address is shown instead of PC. It is followed by the file containing the code. Of course, the address doesn't make much sense without resolving it to a symbol. This can be done with the "stack" tool. Download stack here.
I/DEBUG ( 730): #00 pc 0001c630 /system/lib/libhelixplayer.so
I/DEBUG ( 730): #01 pc 0001edca /system/lib/libhelixplayer.so
I/DEBUG ( 730): #02 pc 0001ff0a /system/lib/libhelixplayer.so
I/DEBUG ( 730): #03 pc 000214e0 /system/lib/libutils.so
I/DEBUG ( 730): #04 pc 0000e322 /system/lib/libmediaplayerservice.so
...
I/DEBUG ( 730): #15 pc b0001516 /system/bin/linker
The following is actually the current stack with the stack pointer address and code dump. Each line contains 4 bytes (one machine word), and the address is in ascending order. The words in the stack are mapped onto the memory region it belongs to.
I/DEBUG ( 730): stack:
I/DEBUG ( 730): beaf9898 00016618 [heap]
I/DEBUG ( 730): beaf989c beaf98d0 [stack]
I/DEBUG ( 730): beaf98a0 0000db28 [heap]
I/DEBUG ( 730): beaf98a4 beaf98f8 [stack]
I/DEBUG ( 730): beaf98b8 8021cf4d /system/lib/libhelixplayer.so
I/DEBUG ( 730): beaf98bc 80248f78
I/DEBUG ( 730): #00 beaf98d8 0000d330 [heap]
I/DEBUG ( 730): beaf98dc 00000000
I/DEBUG ( 730): beaf98e0 0000d330 [heap]
I/DEBUG ( 730): beaf98e4 8021edcd /system/lib/libhelixplayer.so
I/DEBUG ( 730): #01 beaf98e8 80248f78
I/DEBUG ( 730): beaf98ec 80248f78
References
Debugging Native Code: http://source.android.com/porting/debugging_native.html
android 底层log分析 内存及backtrace tombstone/crash的更多相关文章
- android 中如何分析内存泄漏
转载:http://blog.csdn.net/fulinwsuafcie/article/details/8363218 前提条件: 1,电脑安装了java 运行环境 2,手机端开启了 USB 调试 ...
- Android Studio +MAT 分析内存泄漏实战
对于内存泄漏,在Android中如果不注意的话,还是很容易出现的,尤其是在Activity中,比较容易出现,下面我就说下自己是如何查找内存泄露的. 首先什么是内存泄漏? 内存泄漏就是一些已经不使用的对 ...
- Android Native/Tombstone Crash Log 详细分析(转)
转自:http://weibo.com/p/230418702c2db50102vc2h Android 虽然已经有好几年了,但是NDK的开放速度却非常缓慢,所以目前网络上针对对Android Nat ...
- android 常见死机问题--log分析
http://blog.csdn.net/fangchongbory/article/details/7645815 android 常见死机问题--log分析============ ...
- Android 性能优化之使用MAT分析内存泄露问题
我们平常在开发Android应用程序的时候,稍有不慎就有可能产生OOM,虽然JAVA有垃圾回收机,但也不能杜绝内存泄露,内存溢出等问题,随着科技的进步,移动设备的内存也越来越大了,但由于Android ...
- Android 性能优化之使用MAT分析内存泄露
转载请注明本文出自xiaanming的博客(http://blog.csdn.net/xiaanming/article/details/42396507),请尊重他人的辛勤劳动成果,谢谢! 我们平常 ...
- Android Studio和MAT结合使用来分析内存问题
Android开发中时常会遇到内存泄漏的问题,而Android系统对单个App又有一定的内存限制,此值可以通过一下方式获取: ActivityManager am = (ActivityManager ...
- Linux内存管理之mmap详解 (可用于android底层内存调试)
注:将android底层malloc换为mmap来获取内存,可将获取到的内存添加tag,从而再利用meminfo进行分析,可单独查看该tag的内存,从而进行分析. 一. mmap系统调用 1. mma ...
- Android最佳性能实践(二)——分析内存的使用情况
由于Android是为移动设备开发的操作系统,我们在开发应用程序的时候应当始终把内存问题充分考虑在内.虽然Android系统拥有垃圾自动回收机制,但这并不意味着我们就可以完全忽略何时去分配或释放内存. ...
随机推荐
- iOS 学习 - 9.Block 入门
来自李明杰的视频. block 用来保存一段代码 block 的标志:^ block 跟函数很像: 1).可以保存代码 2).有返回值 3). 有形参 temp1:没有返回值.没有形参的 blo ...
- iOS开发--关于TableViewCell的可视化设置细节
由于时间问题,本篇博文很简略. 1.关于设置Cell的边距问题
- 安全攻防之SQL注入(通过sqlmap搞定所有问题)
第一步: sqlmap基于Python,所以首先下载: http://yunpan.cn/QiCBLZtGGTa7U 访问密码 c26e 第二步: 安装Python,将sqlmap解压到Python ...
- node.js学习之路
(非原创) 目录 Nodejs的介绍 15个Nodejs应用场景 Nodejs学习路线图 1. Nodejs的介绍 Node.js的是建立在Chrome的JavaScript的运行时,可方便地构建快速 ...
- 使用MiniProfiler给Asp.net MVC和Entity Framework号脉(附源码)
在学习python开发框架pylons/pyramid的过程中,里面有个非常棒的页面性能监控功能,这样在开发过程中,你能清楚的知道当前页面的性能以及其它参数. 这里介绍一下如何给Asp.net MVC ...
- Java Security:Java加密框架(JCA)简要说明
加密服务总是关联到一个特定的算法或类型,它既提供了密码操作(如Digital Signature或MessageDigest),生成或供应所需的加密材料(Key或Parameters)加密操作,也会以 ...
- JDK7学习笔记之基础类型
printf()的基础用法: 变量的基础用法: 字符的输出:
- 将一列包含多个ID拆分多行
看到个不常见的问题~然后在 Inner Sql Server2008 里面找到一个思路. 如果下面的表结构,如何拆分多行并对应员工号呢? 首先创建测试表 CREATE TABLE Department ...
- MySQL 调优基础(三) Linux文件系统
Linux的文件系统有点像MySQL的存储引擎,它支持各种各样的文件系统.它最上层是通过 virtual files system虚拟文件系统作为一个抽象接口层来对外提供调用的.然后下层的各种文件系统 ...
- 将表里的数据批量生成INSERT语句的存储过程 继续增强版
文章继续 桦仔兄的文章 将表里的数据批量生成INSERT语句的存储过程 增强版 继续增强... 本来打算将该内容回复于桦仔兄的文章的下面的,但是不知为何博客园就是不让提交!.... 所以在这里贴出来吧 ...