Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)

在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*

于是写了个转化函数，原型如下：

[java] view plaincopy

  1. <span style="font-size:14px;">char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray,  jbyte *&bytes)
  2. {
  3. char *chars = NULL;
  4. bytes = env->GetByteArrayElements(bytearray, 0);
  5. chars = (char *)bytes;
  6. int chars_len = env->GetArrayLength(bytearray);
  7. chars[chars_len] = 0;
  8. return chars;
  9. }</span>

问题就出在

[java] view plaincopy

  1. <span style="font-size: 14px; color: rgb(255, 0, 0); ">chars[chars_len] = 0;</span>

这句话

假如GetByteArrayElements返回的是abc

则chars_len值为3

而chars[3]=0就等于是数组越界访问修改了

这样无形当中就破坏了堆内存给程序留下安全隐患

到特定时候就会触发错误爆发

后函数改为：

[java] view plaincopy

  1. <span style="font-size:14px;">char* ConvertJByteaArrayToChars(JNIEnv *env, jbyteArray bytearray,  jbyte *&bytes)
  2. {
  3. char *chars = NULL;
  4. bytes = env->GetByteArrayElements(bytearray, 0);
  5. int chars_len = env->GetArrayLength(bytearray);
  6. chars = new char[chars_len + 1];
  7. memcpy(chars, bytes, chars_len);
  8. chars[chars_len] = 0;
  9. return chars;
  10. }</span>

就没有问题了

在调用函数处处理了char*之后再delete掉就ok了

哎，C++的指针真是让人又爱又恨

以后大家遇到类似问题

还是好好检查下native代码

看看有没有指针操作不当的问题

指针有风险，操作需谨慎

仅以此文小记，希望对大家有帮助~

时间： 2024-11-07 11:05:04

Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)的相关文章

Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 3661 (ervice.Executor)

前言:当我们在android中的使用JNI下编译的.so库时,很有可能底层编译好的native method出现异常,而且底层并没有对这个异常进行捕捉,这样在我们APK上就是表现为退出程序,查看打印信息,出现的提示是:A/libc(2730): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 3661 (ervice.Executor).这个是由android linux 内核libc函数抛出的一个打印,从上面我们只能知道内存操作

求大神相助,关于 Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 1531

============问题描述============ 这个问题在网上查找了较多的资料 首先这是一个底层的错误 有人说这个是因为多线程互斥的问题,要加synchronized 有人说是因为jni问题 不过都没有解决我的问题,我发觉很多人都提到个问题 就是在2.x的系统就没有问题,放到4.x的系统就有问题了 我的也是这样的,有哪位大牛知道这个是什么问题吗? 有人说改SDl版本就可以了,这个怎么搞? ============解决方案1============ 你在什么情况下报的这个错呢,把log帖

关于cocos2dx 3.0升级崩溃报错(unable to load native library) 和(Fatal signal 11 (SIGSEGV) at 0x00000000)

最近一直在Windows平台开发cocos-2dx游戏,期间做了一次引擎升级,升级到了3.0正式版本.Windows平台上表现很正常,没有出现什么问题. 上周五准备发布一个安卓包,编译很轻松的就过了,没有花费多少时间,但是安装到手机后,发现运行就崩溃了.没办法只好用模拟机调试,再次吐槽Android的模拟器,真的太他妈慢了,不到万不得已我真的不想再去用它,google真的应该好好整一下了. 好不容易运行起来了,看到崩溃的时候logcat的报错是"unable to load native lib

Android:Fatal signal 11 (SIGSEGV), code 1, fault addr

游戏出现死机,错误为: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xfffffffc in tid 9811 (GLThread 205) 或者 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xfffffffc 解决方案: 1.继续往下查看日志,知道类似下面这条: #00 pc 0085ed5e  /data/app/cn.kvu.doudizhu-1/lib/arm/libcoc

Fatal signal 11 (SIGSGV) at 0x00002820 (code=1),thread 23696 (xvdy.oa:vitamio)

修这个bug真的让人生不如死的感觉,太苦逼了! 首先叙述一下我的报错环境:在这里,我是在做一个视频播放软件.然后在编程过程中其他都是OK的,也就是说,我所做的这个视频播放如果使用第一次进入的时候,对播放任何的电影视频都不会报错崩掉.但是,由于我所要完成的这个视频播放要求较高(要播放连续剧).在当前页面点击连续剧的选集要进行当前选中的视频进行切换.然后,问题就出现了!党正在播放当前选集然后点击其他任何一集都会报错而崩掉!!并报错上面图片的错误...... 然后在网上收索了好多的帖子,都和我的情况不

Fatal signal xx (SIGSEGV) at

Fatal signal 11问题的解决方法 http://blog.csdn.net/tankai19880619/article/details/9004619 Fatal signal xx (SIGSEGV) at xxxxxx 错误定位代码的解决方法 http://zzhhui.blog.sohu.com/266543920.html Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 25427 (pool-1-threa

[cocos2d-x][apk打包]［Fatal signal 11］［andriod］Eclipse编译Fatal signal 11报错－都是字符赋值惹的祸

流程重现: 使用coco2d-x制作了一个2048,在xcode模拟器运行以及在pad上真机调试都是没有问题的,但是在使用eclipse调试打包android能够运行,但是进入游戏之后会在随机的地方闪退,debug模式报错为: 10-20 11:48:36.413: A/libc(17408): Fatal signal 11 (SIGSEGV) at 0x68d7b0b8 (code=2), thread 17426 (Thread-7958) 在网上查到关于这个问题的n中说法,包括andro

NDK 编译armebai-v7a的crash Fatal signal 7 (SIGSEGV) 错误解决

一直都是编译armabi的,没有任何问题,这个架构是软件模拟浮点运算的. 后来看到NDK文档上说armabi-v7a是针对有硬件处理浮点计算的arm cpu的. 于是就修改配置编译armebai-v7a的so文件. 结果是编译没问题,一运行就是crash掉,Fatal signal 7 (SIGSEGV)错误. 进过排查才发现,crash掉的仅仅是对一个浮点变量赋值而已. 只不过,这个浮点内存,是一个连续内存中的一部分. 经过排查才发现,这个so文件使用了浮点指令,需要指针4字节对齐.举个例子

call to OpenGL ES API with no current context 和Fatal signal 11

近日在用cocos2dx3.4的时候使用了JNI调用,发现一个现象 当不使用jni的时候完全正常,使用了jni后回去的所有文字都变成黑块,并且有概率程序崩溃,附带出了两个log call to OpenGL ES API with no current context  和 Fatal signal 11 但同样的cocos2dx ,同样的jni代码,另一个项目却正常.找寻了好久之后发现了原因 cocos2dx 3.x以后版本 不再是一个进程跑到底: 引用:"Cocos2d-x从2.x版本到上周