有一句话叫做常在河边走，哪有不湿鞋。我们这些研究和开发Android的工程师正应了这句话，相必大家在调试的时候经常会遇到这么个东西吧
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***Build fingerprint: ‘XXXXXXXXX’pid: 1658, tid: 13086 >>> system_server <<<signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7er0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654dr4 64696f72 r5 00000406 r6 00974130 r7 40d14008r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030d0 4040000040000000 d1 0000004200000003d2 4e72cd924285e370 d3 00e81fe04b1b64d8d4 3fbc71c7009b64d8 d5 3fe999999999999ad6 4010000000000000 d7 4000000000000000d8 4000000000000000 d9 0000000000000000d10 0000000000000000 d11 0000000000000000d12 0000000000000000 d13 0000000000000000d14 0000000000000000 d15 0000000000000000scr 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.socode 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这个目录下。
如果有可能，我带你去远行。
