Fatal signal 11 at 0xdeadbaad 错误怎么找
在android里做ndk编程的时候，碰到个随机性错误
错误信息如下：
05-06 15:59:44.411: A/libc(3347): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
05-06 15:59:44.911: I/DEBUG(3344): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-06 15:59:44.911: I/DEBUG(3344): Build fingerprint: 'i.Kan/full_godbox/godbox:4.0.3/IML74K/eng.mipt.20130428.110435:eng/test-keys'
05-06 15:59:44.911: I/DEBUG(3344): pid: 3347, tid: 3348 >>> com.nef.xxx <<<
05-06 15:59:44.911: I/DEBUG(3344): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
05-06 15:59:44.911: I/DEBUG(3344): r0 deadbaad r1 00d9c060 r2 40000000 r3 00000000
05-06 15:59:44.911: I/DEBUG(3344): r4 00000000 r5 00000027 r6 415bf010 r7 00000062
05-06 15:59:44.911: I/DEBUG(3344): r8 415bf018 r9 00000047 10 100ffb94 fp 100ffbd8
05-06 15:59:44.911: I/DEBUG(3344): ip ffffffff sp 100ffb50 lr 40071121 pc 4006d880 cpsr 60000030
05-06 15:59:44.911: I/DEBUG(3344): d0 400000003eaaaaab d1 3ff000003f800000
05-06 15:59:44.911: I/DEBUG(3344): d2 457ff80000000fff d3 000000003f000000
05-06 15:59:44.911: I/DEBUG(3344): d4 00001fff00000000 d5 3fe999999999999a
05-06 15:59:44.911: I/DEBUG(3344): d6 3ff0000000000000 d7 3eaaaaab3f800000
05-06 15:59:44.911: I/DEBUG(3344): d8 0000000000000000 d9 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d10 0000000000000000 d11 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d12 0000000000000000 d13 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d14 0000000000000000 d15 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): scr 80000012
05-06 15:59:45.011: I/DEBUG(3344): #00 pc 00017880 /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): #01 pc 00007d8e /system/lib/libcutils.so (mspace_free)
05-06 15:59:45.011: I/DEBUG(3344): #02 pc 0007b746 /system/lib/libdvm.so (_Z21dvmHeapSourceFreeListjPPv)
05-06 15:59:45.011: I/DEBUG(3344): #03 pc 00042f88 /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #04 pc 00032fc8 /system/lib/libdvm.so (_Z22dvmHeapBitmapSweepWalkPK10HeapBitmapS1_jjPFvjPPvS2_ES2_)
05-06 15:59:45.011: I/DEBUG(3344): #05 pc 00042f44 /system/lib/libdvm.so (_Z27dvmHeapSweepUnmarkedObjectsbbPjS_)
05-06 15:59:45.011: I/DEBUG(3344): #06 pc 000336ac /system/lib/libdvm.so (_Z25dvmCollectGarbageInternalPK6GcSpec)
05-06 15:59:45.011: I/DEBUG(3344): #07 pc 0007bc1c /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #08 pc 0005f906 /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #09 pc 00012e04 /system/lib/libc.so (__thread_entry)
05-06 15:59:45.011: I/DEBUG(3344): #10 pc 00012958 /system/lib/libc.so (pthread_create)
05-06 15:59:45.011: I/DEBUG(3344): code around pc:
05-06 15:59:45.011: I/DEBUG(3344): 4006d860 4623b15c 2c006824 e026d1fb b12368db \.#F$h.,..&..h#.
05-06 15:59:45.011: I/DEBUG(3344): 4006d870 21014a17 6011447a 48124798 24002527 .J.!zD.`.G.H'%.$
05-06 15:59:45.011: I/DEBUG(3344): 4006d880 f7f47005 2106ee60 eeeef7f5 460aa901 .p..`..!.......F
05-06 15:59:45.011: I/DEBUG(3344): 4006d890 f04f2006 94015380 94029303 eab8f7f5 . O..S..........
05-06 15:59:45.011: I/DEBUG(3344): 4006d8a0 4622a905 f7f52002 f7f4eac2 2106ee4c .."F. ......L..!
05-06 15:59:45.011: I/DEBUG(3344): code around lr:
05-06 15:59:45.011: I/DEBUG(3344): 40071100 41f0e92d 46804c0c 447c2600 68a56824 -..A.L.F.&|D$h.h
05-06 15:59:45.011: I/DEBUG(3344): 40071110 e0076867 300cf9b5 dd022b00 47c04628 gh.....0.+..(F.G
05-06 15:59:45.011: I/DEBUG(3344): 40071120 35544306 37fff117 6824d5f4 d1ee2c00 .CT5...7..$h.,..
05-06 15:59:45.011: I/DEBUG(3344): 40071130 e8bd4630 bf0081f0 000283da 41f0e92d 0F..........-..A
05-06 15:59:45.011: I/DEBUG(3344): 40071140 fb01b086 9004f602 461f4815 4615460c .........H.F.F.F
05-06 15:59:45.011: I/DEBUG(3344): memory map around addr deadbaad:
05-06 15:59:45.011: I/DEBUG(3344): be97c000-be99d000 [stack]
05-06 15:59:45.011: I/DEBUG(3344): (no map for address)
05-06 15:59:45.011: I/DEBUG(3344): ffff0000-ffff1000 [vectors]
05-06 15:59:45.011: I/DEBUG(3344): stack:
05-06 15:59:45.011: I/DEBUG(3344): 100ffb10 4009965c /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb14 00d9c060 [heap]
05-06 15:59:45.011: I/DEBUG(3344): 100ffb18 00000a96
05-06 15:59:45.011: I/DEBUG(3344): 100ffb1c 4006fecd /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb20 4009970c /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb24 4009e85c
05-06 15:59:45.011: I/DEBUG(3344): 100ffb28 00000000
05-06 15:59:45.011: I/DEBUG(3344): 100ffb2c 40071121 /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb30 00000000
05-06 15:59:45.011: I/DEBUG(3344): 100ffb34 100ffb64
05-06 15:59:45.011: I/DEBUG(3344): 100ffb38 415bf010 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): 100ffb3c 00000062
05-06 15:59:45.011: I/DEBUG(3344): 100ffb40 415bf018 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): 100ffb44 4007028d /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb48 df0027ad
05-06 15:59:45.021: I/DEBUG(3344): 100ffb4c 00000000
05-06 15:59:45.021: I/DEBUG(3344): #00 100ffb50 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb54 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb58 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb5c 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb60 00cf2780 [heap]
05-06 15:59:45.021: I/DEBUG(3344): 100ffb64 fffffbdf
05-06 15:59:45.021: I/DEBUG(3344): 100ffb68 00000020
05-06 15:59:45.021: I/DEBUG(3344): 100ffb6c 00000020
05-06 15:59:45.021: I/DEBUG(3344): 100ffb70 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb74 40018d91 /system/lib/libcutils.so
05-06 15:59:45.021: I/DEBUG(3344): #01 100ffb78 00cf2780 [heap]
05-06 15:59:45.021: I/DEBUG(3344): 100ffb7c 4162fe00 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): 100ffb80 100ffcf4
05-06 15:59:45.021: I/DEBUG(3344): 100ffb84 00000062
05-06 15:59:45.021: I/DEBUG(3344): 100ffb88 415bf018 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): 100ffb8c 40800749 /system/lib/libdvm.so
05-06 15:59:45.661: I/BootReceiver(1265): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
05-06 15:59:45.671: I/DEBUG(3344): debuggerd committing suicide to free the zombie!
05-06 15:59:45.671: I/DEBUG(3440): debuggerd: Apr 28 2013 11:10:17
05-06 15:59:45.681: D/Zygote(917): Process 3347 terminated by signal (11)
05-06 15:59:45.681: I/ActivityManager(1265): haveBgApp:true app.setAdj:10
05-06 15:59:45.681: I/ActivityManager(1265): Process com.nef.xxx (pid 3347) has died.
05-06 15:59:45.681: W/ActivityManager(1265): Scheduling restart of crashed service com.nef.xxx/.service.renderService in 5000ms
05-06 15:59:48.241: D/PowerManagerService(1265): Screen must keep ON all the time! TimeoutTask return.
05-06 15:59:50.691: D/dalvikvm(3441): Late-enabling CheckJNI
05-06 15:59:50.701: I/ActivityManager(1265): Start proc com.nef.xxx for service com.nef.xxx/.service.renderService: pid=3441 uid=10009 gids={1015, 3003}
05-06 15:59:50.721: I/dalvikvm(3441): Turning on JNI app bug workarounds for target SDK version 9...
这个错误并不是再调用某个jni接口的时候发生的
而是反复调用之后（或是上层进行了一些其他操作后）冷不丁的蹦出来
程序虽然没有弹框，但进程已经挂了
这种随机问题最难搞了，很难确定哪行代码出的问题
于是各种百度谷歌寻求解决方案
其中最重要的错误信息是 Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
网上也有很多人都遇到类似的问题
主要症结还是内存操作的问题
在经过各种排查测试后，折腾了老半天
终于找到问题所在，的确是内存操作有误
在jni里，我想把jbyteArray转化成char*
于是写了个转化函数，原型如下：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray, jbyte *&bytes)
{
char *chars = NULL;
bytes = env->GetByteArrayElements(bytearray, 0);
chars = (char *)bytes;
int chars_len = env->GetArrayLength(bytearray);
chars[chars_len] = 0;
return chars;
}
问题就出在
chars[chars_len] = 0;
这句话
假如GetByteArrayElements返回的是abc
则chars_len值为3
而chars[3]=0就等于是数组越界访问修改了
这样无形当中就破坏了堆内存给程序留下安全隐患
到特定时候就会触发错误爆发
后函数改为：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray, jbyte *&bytes)
{
char *chars = NULL;
bytes = env->GetByteArrayElements(bytearray, 0);
int chars_len = env->GetArrayLength(bytearray);
chars = new char[chars_len + 1];
memcpy(chars, bytes, chars_len);
chars[chars_len] = 0;
return chars;
}
就没有问题了
在调用函数处处理了char*之后再delete掉就ok了
哎，C++的指针真是让人又爱又恨
以后大家遇到类似问题
还是好好检查下native代码
看看有没有指针操作不当的问题
指针有风险，用时需谨慎
仅以此文小记，希望对大家有帮助~
这句话
假如GetByteArrayElements返回的是abc
则chars_len值为3
而chars[3]=0就等于是数组越界访问修改了
这样无形当中就破坏了堆内存给程序留下安全隐患
到特定时候就会触发错误爆发
后函数改为：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray, jbyte *&bytes)
{
char *chars = NULL;
bytes = env->GetByteArrayElements(bytearray, 0);
int chars_len = env->GetArrayLength(bytearray);
chars = new char[chars_len + 1];
memcpy(chars, bytes, chars_len);
chars[chars_len] = 0;
return chars;
}
就没有问题了
在调用函数处处理了char*之后再delete掉就ok了
哎，C++的指针真是让人又爱又恨
以后大家遇到类似问题
还是好好检查下native代码
看看有没有指针操作不当的问题
错误信息如下：
05-06 15:59:44.411: A/libc(3347): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
05-06 15:59:44.911: I/DEBUG(3344): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-06 15:59:44.911: I/DEBUG(3344): Build fingerprint: 'i.Kan/full_godbox/godbox:4.0.3/IML74K/eng.mipt.20130428.110435:eng/test-keys'
05-06 15:59:44.911: I/DEBUG(3344): pid: 3347, tid: 3348 >>> com.nef.xxx <<<
05-06 15:59:44.911: I/DEBUG(3344): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
05-06 15:59:44.911: I/DEBUG(3344): r0 deadbaad r1 00d9c060 r2 40000000 r3 00000000
05-06 15:59:44.911: I/DEBUG(3344): r4 00000000 r5 00000027 r6 415bf010 r7 00000062
05-06 15:59:44.911: I/DEBUG(3344): r8 415bf018 r9 00000047 10 100ffb94 fp 100ffbd8
05-06 15:59:44.911: I/DEBUG(3344): ip ffffffff sp 100ffb50 lr 40071121 pc 4006d880 cpsr 60000030
05-06 15:59:44.911: I/DEBUG(3344): d0 400000003eaaaaab d1 3ff000003f800000
05-06 15:59:44.911: I/DEBUG(3344): d2 457ff80000000fff d3 000000003f000000
05-06 15:59:44.911: I/DEBUG(3344): d4 00001fff00000000 d5 3fe999999999999a
05-06 15:59:44.911: I/DEBUG(3344): d6 3ff0000000000000 d7 3eaaaaab3f800000
05-06 15:59:44.911: I/DEBUG(3344): d8 0000000000000000 d9 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d10 0000000000000000 d11 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d12 0000000000000000 d13 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): d14 0000000000000000 d15 0000000000000000
05-06 15:59:44.911: I/DEBUG(3344): scr 80000012
05-06 15:59:45.011: I/DEBUG(3344): #00 pc 00017880 /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): #01 pc 00007d8e /system/lib/libcutils.so (mspace_free)
05-06 15:59:45.011: I/DEBUG(3344): #02 pc 0007b746 /system/lib/libdvm.so (_Z21dvmHeapSourceFreeListjPPv)
05-06 15:59:45.011: I/DEBUG(3344): #03 pc 00042f88 /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #04 pc 00032fc8 /system/lib/libdvm.so (_Z22dvmHeapBitmapSweepWalkPK10HeapBitmapS1_jjPFvjPPvS2_ES2_)
05-06 15:59:45.011: I/DEBUG(3344): #05 pc 00042f44 /system/lib/libdvm.so (_Z27dvmHeapSweepUnmarkedObjectsbbPjS_)
05-06 15:59:45.011: I/DEBUG(3344): #06 pc 000336ac /system/lib/libdvm.so (_Z25dvmCollectGarbageInternalPK6GcSpec)
05-06 15:59:45.011: I/DEBUG(3344): #07 pc 0007bc1c /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #08 pc 0005f906 /system/lib/libdvm.so
05-06 15:59:45.011: I/DEBUG(3344): #09 pc 00012e04 /system/lib/libc.so (__thread_entry)
05-06 15:59:45.011: I/DEBUG(3344): #10 pc 00012958 /system/lib/libc.so (pthread_create)
05-06 15:59:45.011: I/DEBUG(3344): code around pc:
05-06 15:59:45.011: I/DEBUG(3344): 4006d860 4623b15c 2c006824 e026d1fb b12368db \.#F$h.,..&..h#.
05-06 15:59:45.011: I/DEBUG(3344): 4006d870 21014a17 6011447a 48124798 24002527 .J.!zD.`.G.H'%.$
05-06 15:59:45.011: I/DEBUG(3344): 4006d880 f7f47005 2106ee60 eeeef7f5 460aa901 .p..`..!.......F
05-06 15:59:45.011: I/DEBUG(3344): 4006d890 f04f2006 94015380 94029303 eab8f7f5 . O..S..........
05-06 15:59:45.011: I/DEBUG(3344): 4006d8a0 4622a905 f7f52002 f7f4eac2 2106ee4c .."F. ......L..!
05-06 15:59:45.011: I/DEBUG(3344): code around lr:
05-06 15:59:45.011: I/DEBUG(3344): 40071100 41f0e92d 46804c0c 447c2600 68a56824 -..A.L.F.&|D$h.h
05-06 15:59:45.011: I/DEBUG(3344): 40071110 e0076867 300cf9b5 dd022b00 47c04628 gh.....0.+..(F.G
05-06 15:59:45.011: I/DEBUG(3344): 40071120 35544306 37fff117 6824d5f4 d1ee2c00 .CT5...7..$h.,..
05-06 15:59:45.011: I/DEBUG(3344): 40071130 e8bd4630 bf0081f0 000283da 41f0e92d 0F..........-..A
05-06 15:59:45.011: I/DEBUG(3344): 40071140 fb01b086 9004f602 461f4815 4615460c .........H.F.F.F
05-06 15:59:45.011: I/DEBUG(3344): memory map around addr deadbaad:
05-06 15:59:45.011: I/DEBUG(3344): be97c000-be99d000 [stack]
05-06 15:59:45.011: I/DEBUG(3344): (no map for address)
05-06 15:59:45.011: I/DEBUG(3344): ffff0000-ffff1000 [vectors]
05-06 15:59:45.011: I/DEBUG(3344): stack:
05-06 15:59:45.011: I/DEBUG(3344): 100ffb10 4009965c /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb14 00d9c060 [heap]
05-06 15:59:45.011: I/DEBUG(3344): 100ffb18 00000a96
05-06 15:59:45.011: I/DEBUG(3344): 100ffb1c 4006fecd /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb20 4009970c /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb24 4009e85c
05-06 15:59:45.011: I/DEBUG(3344): 100ffb28 00000000
05-06 15:59:45.011: I/DEBUG(3344): 100ffb2c 40071121 /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb30 00000000
05-06 15:59:45.011: I/DEBUG(3344): 100ffb34 100ffb64
05-06 15:59:45.011: I/DEBUG(3344): 100ffb38 415bf010 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): 100ffb3c 00000062
05-06 15:59:45.011: I/DEBUG(3344): 100ffb40 415bf018 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.011: I/DEBUG(3344): 100ffb44 4007028d /system/lib/libc.so
05-06 15:59:45.011: I/DEBUG(3344): 100ffb48 df0027ad
05-06 15:59:45.021: I/DEBUG(3344): 100ffb4c 00000000
05-06 15:59:45.021: I/DEBUG(3344): #00 100ffb50 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb54 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb58 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb5c 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb60 00cf2780 [heap]
05-06 15:59:45.021: I/DEBUG(3344): 100ffb64 fffffbdf
05-06 15:59:45.021: I/DEBUG(3344): 100ffb68 00000020
05-06 15:59:45.021: I/DEBUG(3344): 100ffb6c 00000020
05-06 15:59:45.021: I/DEBUG(3344): 100ffb70 00000000
05-06 15:59:45.021: I/DEBUG(3344): 100ffb74 40018d91 /system/lib/libcutils.so
05-06 15:59:45.021: I/DEBUG(3344): #01 100ffb78 00cf2780 [heap]
05-06 15:59:45.021: I/DEBUG(3344): 100ffb7c 4162fe00 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): 100ffb80 100ffcf4
05-06 15:59:45.021: I/DEBUG(3344): 100ffb84 00000062
05-06 15:59:45.021: I/DEBUG(3344): 100ffb88 415bf018 /dev/ashmem/dalvik-heap (deleted)
05-06 15:59:45.021: I/DEBUG(3344): 100ffb8c 40800749 /system/lib/libdvm.so
05-06 15:59:45.661: I/BootReceiver(1265): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE)
05-06 15:59:45.671: I/DEBUG(3344): debuggerd committing suicide to free the zombie!
05-06 15:59:45.671: I/DEBUG(3440): debuggerd: Apr 28 2013 11:10:17
05-06 15:59:45.681: D/Zygote(917): Process 3347 terminated by signal (11)
05-06 15:59:45.681: I/ActivityManager(1265): haveBgApp:true app.setAdj:10
05-06 15:59:45.681: I/ActivityManager(1265): Process com.nef.xxx (pid 3347) has died.
05-06 15:59:45.681: W/ActivityManager(1265): Scheduling restart of crashed service com.nef.xxx/.service.renderService in 5000ms
05-06 15:59:48.241: D/PowerManagerService(1265): Screen must keep ON all the time! TimeoutTask return.
05-06 15:59:50.691: D/dalvikvm(3441): Late-enabling CheckJNI
05-06 15:59:50.701: I/ActivityManager(1265): Start proc com.nef.xxx for service com.nef.xxx/.service.renderService: pid=3441 uid=10009 gids={1015, 3003}
05-06 15:59:50.721: I/dalvikvm(3441): Turning on JNI app bug workarounds for target SDK version 9...
这个错误并不是再调用某个jni接口的时候发生的
而是反复调用之后（或是上层进行了一些其他操作后）冷不丁的蹦出来
程序虽然没有弹框，但进程已经挂了
这种随机问题最难搞了，很难确定哪行代码出的问题
于是各种百度谷歌寻求解决方案
其中最重要的错误信息是 Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
网上也有很多人都遇到类似的问题
主要症结还是内存操作的问题
在经过各种排查测试后，折腾了老半天
终于找到问题所在，的确是内存操作有误
在jni里，我想把jbyteArray转化成char*
于是写了个转化函数，原型如下：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray, jbyte *&bytes)
{
char *chars = NULL;
bytes = env->GetByteArrayElements(bytearray, 0);
chars = (char *)bytes;
int chars_len = env->GetArrayLength(bytearray);
chars[chars_len] = 0;
return chars;
}
问题就出在
chars[chars_len] = 0;
这句话
假如GetByteArrayElements返回的是abc
则chars_len值为3
而chars[3]=0就等于是数组越界访问修改了
这样无形当中就破坏了堆内存给程序留下安全隐患
到特定时候就会触发错误爆发
后函数改为：
char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray, jbyte *&bytes)
{
char *chars = NULL;
bytes = env->GetByteArrayElements(bytearray, 0);
int chars_len = env->GetArrayLength(bytearray);
chars = new char[chars_len + 1];
memcpy(chars, bytes, chars_len);
chars[chars_len] = 0;
return chars;
}
就没有问题了
在调用函数处处理了char*之后再delete掉就ok了
哎，C++的指针真是让人又爱又恨
以后大家遇到类似问题
还是好好检查下native代码
看看有没有指针操作不当的问题
指针有风险，用时需谨慎
仅以此文小记，希望对大家有帮助~
危梦北豆： 可进行以下操作:1.重新开关机2.卸载近期安装的第三方软件后观察3.备份手机数据(电话簿、短信息、多媒体文件等),恢复出厂设置 如果恢复出厂设置问题依然存在,建议将手机送至就近的服务中心进行检测及进一步处理
芷江侗族自治县15552683331： Android运行时随机出现Fatal signal 11 (SIGSEGV) at 0xa7543c80 (code=2), thread 3459 (Thread - 204) - ？
危梦北豆： 很多错误都会导致这个问题, 基本上只要程序crash了, 就会有个fatal什么的, 建议从这个报错开始往上跟踪log,看有没有什么其他error信息
芷江侗族自治县15552683331： 遇到Fatal signal 11 二人台是什么求解答答 - ？
危梦北豆： Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 1405 (.novonity.uchat) 应该是JNI代码的问题,0xdeadbaad 这个地址一般用于标识一个被free掉的指针 可以编译一个debug的so库,然后等崩溃后看一下调用堆栈.
芷江侗族自治县15552683331： Android、Java开发相关:A/libc(28088): Fatal signal 11 (SIGSEGV) at 0x616f708c (code=1), - ？
危梦北豆： 这个错误一般是出现了内存泄露问题,可以检查一下是否出现了野指针,或者某些线程或者实例是否及时关闭,谢谢
芷江侗族自治县15552683331： 遇到Fatal signal 11 求解答 - ？
危梦北豆： 通过对比编译环境发现,在dest赋值处;用到的头文件位置不同,导致结果差异.通过重新设置头文件路径,问题解决.三、思考 目前掌握的结局signal 11故障的方法是使用交叉编译工具链给我们提供的arm-none-linux-gnueabi-addr2line工具,通过地址定位源文件中出错的函数或具体行数.四、补充:Fatal signal 8 (SIGFPE) 最近在帮助同事看一个打印堆栈问题时发现,程序并没有被kill掉[plain] view plaincopy在CODE上查看代码片派生到我的代码片
芷江侗族自治县15552683331： Fatal signal 11 at 0xdeadbaad 错误怎么找 - ？
危梦北豆： 这句话假如GetByteArrayElements返回的是abc则chars_len值为3而chars[3]=0就等于是数组越界访问修改了这样无形当中就破坏了堆内存给程序留下安全隐患到特定时候就会触发错误爆发后函数改为:char* ConvertJByteaArrayToChars(JNIEnv *...
芷江侗族自治县15552683331： 求助:vlc打包混淆后,出现Fatal signal - ？
危梦北豆： 对vlc混淆.加上-keep class org.videolan.vlc.** {*;}
芷江侗族自治县15552683331： 安卓调试的时候出现这么个错误 libc fatal signal 11 sigsegv at 0x00000000 code 1 - ？
危梦北豆： 我大胆猜测一下,这个问题应该是你的SDK的问题,如果你是使用Eclipse+插件开发Android我不推荐,这样会出现很多奇奇怪怪的问题,我建议使用专门的开发工具ADT
芷江侗族自治县15552683331： 这个C程序为什么会出现signal11 - ？
危梦北豆： signal11 -- 信号11 (表示有错) c 语言要先写声明,后写语句. m 数组用动态分配方法 获得 存储空间. 循环到字符串长度,不要用 100. #include<stdio.h> int main() { int a=0,b=0,c=0; char (*m)[100]; //声明指针 scanf(＂%d＂,&a); m = (char (...
芷江侗族自治县15552683331： fluent提示Error: received a fatal signal (Segmentation fault). - ？
危梦北豆： 这是 fluent 界面程序出错了 比如在 fluent 要更新窗口内容时,显示窗口已经被关闭了,导致访问出错 有时操作显示窗口时也会出现这个错误
