Fatal signal 11 (SIGSEGV) at 0x0000130f (code=1), thread xxx (Thread-xx)

先展示与问题相关的代码片：

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方法进行捕捉线程之外的问题，多数情况下还是有用的，至于怎么使用请自行百度或者留言探讨。