导致应用程序崩溃问题分析与解决:
- --复现
- --分析
- --解决
- 最后
先展示与问题相关的代码片：
09-04 13:26:32.826 F/libc ( 572): Fatal signal 11 (SIGSEGV) at 0x0000130f (code=1), xxxx 844 (Thread-46)
09-04 13:26:32.936 I/DEBUG ( 103): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-04 13:26:32.936 I/DEBUG ( 103): Build fingerprint: 'rockchip/rk3188/rk3188:4.4.4/KTU84Q/eng.root.20151128.163335:eng/test-keys'
09-04 13:26:32.936 I/DEBUG ( 103): Revision: '0'
09-04 13:26:32.936 I/DEBUG ( 103): pid: 572, tid: 844, name: Thread-46 >>> com.xxx.xxxxxx <<<
09-04 13:26:32.936 I/DEBUG ( 103): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000130f
09-04 13:26:33.016 I/DEBUG ( 103): r0 000012ef r1 41e8e2a8 r2 fffffea0 r3 415d7c74
09-04 13:26:33.016 I/DEBUG ( 103): r4 42741d98 r5 415dc1f0 r6 00000000 r7 41e8e2a8
09-04 13:26:33.016 I/DEBUG ( 103): r8 80000000 r9 415644f0 sl 41e8e2a8 fp 42741e00
09-04 13:26:33.016 I/DEBUG ( 103): ip 41e8f1e8 sp 6ccb2b28 lr 41555efc pc 415642d8 cpsr 800f0010
09-04 13:26:33.016 I/DEBUG ( 103): d0 0000000000000000 d1 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d2 0000000000000000 d3 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d4 3ff0000000000000 d5 529292949610636a
09-04 13:26:33.016 I/DEBUG ( 103): d6 0000001900000000 d7 4040000000000003
09-04 13:26:33.016 I/DEBUG ( 103): d8 4040000000000003 d9 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d10 0000000000000000 d11 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d12 0000000000000000 d13 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d14 0000000000000000 d15 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d16 000000000000001c d17 090a0d3e31bc80e5
09-04 13:26:33.016 I/DEBUG ( 103): d18 3ff0000000000000 d19 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d20 0000000000000000 d21 000c000c000c000c
09-04 13:26:33.016 I/DEBUG ( 103): d22 0010001000100010 d23 0000000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d24 0000000000000000 d25 3980000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d26 0707070703030303 d27 e03b3b3bd74e4e4e
09-04 13:26:33.016 I/DEBUG ( 103): d28 7a14141410000000 d29 2ca8000000000000
09-04 13:26:33.016 I/DEBUG ( 103): d30 3ff0000000000000 d31 4024000000000000
09-04 13:26:33.016 I/DEBUG ( 103): scr 80000010
09-04 13:26:33.026 I/DEBUG ( 103):
09-04 13:26:33.026 I/DEBUG ( 103): backtrace:
09-04 13:26:33.026 I/DEBUG ( 103): #00 pc 000372d8 /system/lib/libdvm.so
09-04 13:26:33.026 I/DEBUG ( 103): #01 pc 00028ef8 /system/lib/libdvm.so (dvmHeapBitmapScanWalk(HeapBitmap*, void (*)(Object*, void*, void*), void*)+100)–复现
多的不说直入主题，在项目中有个需要调用so库其中的一些方法获取返回值的操作，就是把固定大小的byte数组当参数传进去，.so里的方法负责给传过来的数组赋值，我这边再拿到该数组进行下一步处理。
关键是整个过程都是在try…catch中，按道理说就算有错也不至于程序崩溃，打印logcat除了上面的代码外找不到其他有用信息，最后经过多次复现观察发现，.so是将原数组整个赋值给传进去的数组的，所以传进去的时候数组固定在合理范围内的固定长度，而在调用.so里的方法时某一时刻赋值的数组长度远远超过传进去的数组长度，程序立马崩溃，于是就确定找到了问题的根源。
–分析
虽然整个过程在try…catch中，但要知道不是所有代码在其之中就不会产生严重问题导致程序崩溃，比如try…catch中new一个Thread,该Thread中发生错误catch也是捕捉不到的。
因为程序调用.so的方法，所以该方法也是运行在你的程序之中的，里面的方法产生错误也就代表你的程序产生了错误，崩溃理所当然。
至于更对这种问题更深层的理解，建议多百度找找这方面的知识，限于本人能力有限，就分析到此。
–解决
找公司写.so的同事，商量解决或你的程序在传数组的时候传入长度更大的数组，当然多数情况还是.so的问题。
最后
这可能是产生该问题的一种情况，不是可能是一定！
很多时候是无从下手的，推荐使用java里的
Thread.setDefaultUncaughtExceptionHandler方法进行捕捉线程之外的问题，多数情况下还是有用的，至于怎么使用请自行百度或者留言探讨。