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

本文记录了一个在Android NDK编程中遇到的随机性SIGSEGV错误,详细解析了错误原因,并给出了具体的解决办法,强调了在JNI开发中正确处理内存的重要性。

在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 plain copy
 
  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.   
  10.   
  11. }</span>  

问题就出在

 

[java]  view plain copy
 
  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 plain copy
 
  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代码

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

指针有风险,操作需谨慎

 

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

<think>好的,用户遇到了Unity游戏在模拟器中出现的致命信号11SIGSEGV错误,具体是SEGV_MAPERR类型。这个问题通常与内存访问错误有关,比如访问了未初始化或已释放的内存区域,或者空指针解引用。根据用户提供的引用内容,特别是引用[1]提到的Application.quit()导致的问题,以及引用[2]中的空指针错误,我需要综合这些信息来提出解决方案。 首先,用户的问题是在模拟器中出现的,可能涉及到代码中的退出逻辑或者资源释放的问题。引用[1]指出,使用Application.quit()在某些安卓设备上会导致crash,可能涉及到Unity与安卓平台的交互问题。引用[2]中的空指针错误提示可能是由于模型推理时的指针问题,但这里用户的问题可能更偏向于Unity本身的代码或模拟器设置。 接下来,我需要考虑常见的解决方案。根据引用[3],用户通过调整SDK和NDK路径解决了问题,这可能涉及到开发环境的配置。因此,检查NDK版本和路径是否正确是必要的。同时,模拟器的设置,如使用x86架构可能导致兼容性问题,建议使用ARM64镜像。 此外,内存泄漏或资源未正确释放也可能导致SIGSEGV错误。用户需要检查代码中是否有在退出时未正确销毁的对象,或者协程未正确停止的情况。开启Unity的深层次内存检测工具,如Memory Profiler,可以帮助定位问题。 最后,如果问题依旧存在,建议用户尝试更新Unity版本或模拟器,以及查看官方文档和社区是否有类似问题的解决方案。需要综合环境配置、代码审查和工具检测来全面解决这个问题。</think>### 逐步解决方案:Unity模拟器中SIGSEGV (SEGV_MAPERR) 错误排查 1. **检查代码中的退出逻辑** - 避免直接使用 `Application.Quit()` 退出,尤其是在安卓平台上。可以尝试通过调用 `System.Diagnostics.Process.GetCurrentProcess().Kill()` 或 **延迟退出** 的方式避免资源冲突[^1]。 - 示例代码: ```csharp IEnumerator SafeExit() { yield return new WaitForSeconds(0.5f); // 延迟释放资源 Application.Quit(); } ``` 2. **验证内存访问安全性** - 检查所有 **指针操作、数组越界、空引用** 的代码段。例如引用[2]中提到的空指针解引用问题(`output_tensor_array[col + 1024 * row] == 2`),需确保指针已正确初始化且内存已分配。 - 使用 `Debug.Log` 或断点验证关键变量的有效性。 3. **更新NDK/SDK版本与环境配置** - 确保NDK版本与Unity兼容,避免使用过时的NDK(如r14b)。建议升级至 **NDK r21+**,并在Unity Editor的 `Build Settings > Android > NDK` 中指定路径[^3]。 - 检查 `local.properties` 文件中的路径是否包含特殊字符或空格,建议使用纯英文路径。 4. **调整模拟器配置** - 使用 **ARM64系统镜像** 替代x86镜像(某些Unity功能在x86模拟器中存在兼容性问题)。 -Android Studio的AVD Manager中,为模拟器分配更多内存(建议4GB以上)。 5. **启用Unity深层次调试工具** - 在 `Edit > Project Settings > Player > Other Settings` 中开启: - **Script Debugging** 和 **Wait For Managed Debugger**(捕获C#层错误- **Deep Profiling Support**(检测内存泄漏) 6. **检查第三方插件与资源释放** - 若使用了 **原生插件(如MNN、OpenCV)**,确保其与模拟器架构(ARM/x86)匹配。 - 在 `OnDestroy()` 或 `OnApplicationQuit()` 中手动释放非托管资源(如文件句柄、网络连接)。 --- ### 相关问题 1. 如何检测Unity中的内存泄漏? 2. 安卓模拟器运行Unity游戏时出现黑屏如何解决? 3. 为什么Unity的协程(Coroutine)可能导致崩溃? : 引用[1]: Unity Android平台Application.quit()引起的signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr ... [^2]: 引用[2]: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0(Cause: null pointer dereference) : 引用[3]: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8。我的解决办法: 把local.propertiers文件改成: sdk.dir=D:\Downloads\AS\sdk1\sdk1 ndk.dir=D:\Downloads\AS\sdk1\sdk1\ndk\android-ndk-r14b
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值