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的环境下完成。