Android程序运行报错"Process xxxx has died"原因查找

      在我们的程序挂掉之后，我们抓取log分析，有时候有以下提示：

      "I/ActivityManager( 2212): Process com.seven.test (pid 2758) has died."

      这句话的意思就是说我们的程序主进程已经死掉了，这肯定不是我们所期望的啊，那么这种错误如何分析呢？以下是我的分析过程

      1.首先找到关键log

I/DEBUG   ( 2104): pid: 2758, tid: 3374  >>> com.seven.test <<<
I/DEBUG   ( 2104): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 3128b000
I/DEBUG   ( 2104):  r0 0000006c  r1 312873ff  r2 00000001  r3 00000000
I/DEBUG   ( 2104):  r4 3128b001  r5 002625a0  r6 00000030  r7 31287444
I/DEBUG   ( 2104):  r8 4120bc36  r9 4120d264  10 412103d0  fp 4120bf18
I/DEBUG   ( 2104):  ip 4120d2dc  sp 31287410  lr 41208297  pc 41208306  cpsr 20000030
I/DEBUG   ( 2104):  d0  6265726f7473202c  d1  6d756e20646e6165
I/DEBUG   ( 2104):  d2  4a5f6e6f6d6d6f61  d3  6e6f6d6d6f436964
I/DEBUG   ( 2104):  d4  c1b9a500c1b5a500  d5  40e0000000000007
I/DEBUG   ( 2104):  d6  c1d80000ffffffe5  d7  7149f2ca00000000
I/DEBUG   ( 2104):  d8  0000000042f61800  d9  42f6180042f61800
I/DEBUG   ( 2104):  d10 446147ae2b09cae8  d11 00000000446147ae
I/DEBUG   ( 2104):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 2104):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 2104):  d16 7eb0fe582b07fb58  d17 4010000000000000
I/DEBUG   ( 2104):  d18 0000000000000000  d19 0000000000000000
I/DEBUG   ( 2104):  d20 3ff0000000000000  d21 8000000000000000
I/DEBUG   ( 2104):  d22 0000000000000000  d23 0000fd010000fd22
I/DEBUG   ( 2104):  d24 0000050000000520  d25 0000050000000520
I/DEBUG   ( 2104):  d26 0000050000000520  d27 0000050000000520
I/DEBUG   ( 2104):  d28 0000000000000000  d29 3ff0000000000000
I/DEBUG   ( 2104):  d30 0000000000000000  d31 3ff0000000000000
I/DEBUG   ( 2104):  scr 60000012
I/DEBUG   ( 2104): 
I/DEBUG   ( 2104):          #00  pc 00008306  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):          #01  pc 000083d4  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104): 
I/DEBUG   ( 2104): code around pc:
I/DEBUG   ( 2104): 412082e4 447b4a0d 33184479 f7fa447a f04fecea 
I/DEBUG   ( 2104): 412082f4 e00930ff 280a3401 f804d103 20000c01 
I/DEBUG   ( 2104): 41208304 f804e002 e7e30c01 70212100 bf00bd70 
I/DEBUG   ( 2104): 41208314 0000222e 00003897 0000390a 4ff0e92d 
I/DEBUG   ( 2104): 41208324 81acf8df 91acf8df 6d84f5ad 468244f8 
I/DEBUG   ( 2104): 
I/DEBUG   ( 2104): code around lr:
I/DEBUG   ( 2104): 41208274 22002c8c f44f9300 46136080 f7fa4629 
I/DEBUG   ( 2104): 41208284 2801ee5e d1074602 f10d4620 f7fa0197 
I/DEBUG   ( 2104): 41208294 f89dedba e00b0097 49094808 44784a09 
I/DEBUG   ( 2104): 412082a4 030cf110 447a4479 f7fa2003 2000ed0a 
I/DEBUG   ( 2104): 412082b4 bd30b027 000f4240 fff0bdc0 00002272 
I/DEBUG   ( 2104): 
I/DEBUG   ( 2104): stack:
I/DEBUG   ( 2104):     312873d0  00000000  
I/DEBUG   ( 2104):     312873d4  00000000  
I/DEBUG   ( 2104):     312873d8  00000000  
I/DEBUG   ( 2104):     312873dc  00000000  
I/DEBUG   ( 2104):     312873e0  00000000  
I/DEBUG   ( 2104):     312873e4  00000000  
I/DEBUG   ( 2104):     312873e8  00000000  
I/DEBUG   ( 2104):     312873ec  00000000  
I/DEBUG   ( 2104):     312873f0  00000000 
I/DEBUG   ( 2104):     312873f4  00000002  
I/DEBUG   ( 2104):     312873f8  0007a11d  
I/DEBUG   ( 2104):     312873fc  6cd0b0be  
I/DEBUG   ( 2104):     31287400  4120bb83  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     31287404  3128b000  
I/DEBUG   ( 2104):     31287408  df002777  
I/DEBUG   ( 2104):     3128740c  e3a070ad 
I/DEBUG   ( 2104): #00 31287410  4120bb83  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     31287414  31287644  
I/DEBUG   ( 2104):     31287418  4120a53c  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     3128741c  412083d9  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104): #01 31287420  31287444  
I/DEBUG   ( 2104):     31287424  00000001  
I/DEBUG   ( 2104):     31287428  4120bb83  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     3128742c  00000007  
I/DEBUG   ( 2104):     31287430  00000000  
I/DEBUG   ( 2104):     31287434  31287b00  
I/DEBUG   ( 2104):     31287438  002625a0  
I/DEBUG   ( 2104):     3128743c  4120a53c  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     31287440  4120bb83  /data/data/com.seven.test/files/mylib.so
I/DEBUG   ( 2104):     31287444  00000000  
I/DEBUG   ( 2104):     31287448  00000000  
I/DEBUG   ( 2104):     3128744c  00000000  
I/DEBUG   ( 2104):     31287450  00000000  
I/DEBUG   ( 2104):     31287454  00000000  
I/DEBUG   ( 2104):     31287458  00000000  
I/DEBUG   ( 2104):     3128745c  00000000  
I/DEBUG   ( 2104):     31287460  00000000  
I/DEBUG   ( 2104):     31287464  00000000      

        为什么要抓取这段log呢？这得从process xxx has died.这个错误说起，这个错误一般是由内存栈溢出导致的，而导致内存栈溢出的原因很大程度上是由于JNI的调用，在我的测试程序中的确用到了JNI。这个问题就出在C/C++所写的代码中。比如：申请了一个很大的栈空间char[65535]或者在C/C++中递归调用了一个栈方法，也有可能代码上出现非逻辑性错误，但代码判断错误或者没有正常抛出异常等等，从而导致栈溢出等等。

        2.如何分析

       如果单单通过查看log是无法知道具体哪里出错了，所以我们需要反汇编我们调用到的.so库文件，因为C/C++方法都编译在.so库文件中。我们可以通过以下方法反汇编：

      在AndroidSourceCode目录下找到：

      路径：

      AndroidSourceCode/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin

      关键程序：

      有一个arm-eabi-objdump工具可用于反汇编

      在终端中执行方法如下：

      ./arm-eabi-objdump -dS mylib.so > mylib.dump

      最后，打开反汇编之后的libtp.dump，通过搜索找到代码出错地址：00008306  。根据出错地址，我们可以知道在C/C++中具体哪个方法出错了。

      以上步骤均在Ubuntu 10.04的环境下完成。