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

最新推荐文章于 2024-04-11 09:26:27 发布
原创 最新推荐文章于 2024-04-11 09:26:27 发布 · 419 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #安卓 #native app #thread

本文介绍了在Android应用中遇到的一个因调用SO库导致的程序崩溃问题。通过日志分析，发现.so库在赋值过程中超过了传入数组的长度，从而引发崩溃。尽管整个过程在try...catch中，但错误发生在单独的线程中，使得异常无法被捕获。解决方法包括修改.so库或确保传递足够大的数组。此外，建议使用`Thread.setDefaultUncaughtExceptionHandler`来捕获此类线程外异常。

导致应用程序崩溃问题分析与解决:

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

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

Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)问题解决
sonikk的专栏
07-01 8万+
异常出现频率：非必现，乍看不可捉摸。 BUG导致：应用程序崩溃，过一小会儿会自动退出。 Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) 遇到这个问题很无奈，但是经过不断探索终于找到了问题的原因！！！ 这个问题非常不给面子，居然在给上级演示程序的时候突然崩坏！ 哭哭哭！！！NND看老子一会儿怎么治你！！！ 这个是典型
android native开发 错误信息定位：Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 4785 (XXX）
Vaylb的专栏
11-02 3505
最近开始做android底层开发，经常遇到C/C++代码报错，logcat只给出一大串堆栈信息，而无法定位到具体代码段，后来网上搜寻发现可以使用addr2line工具根据出错地址映射到出错行，例如： 11-02 20:01:53.009: A/libc(4785): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 47
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)
热门推荐
蓝斯的专栏
05-07 6万+
在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): *** *** *** *** *** *** *** *** *** *** ***
Fatal signal 11 (SIGSEGV)
u010477502的专栏
02-03 1万+
最近遇到一个问题： Fatal signal 11 (SIGSEGV) at 0x75462000 (code=1), thread 5686 (m.grg.grgverify) 一开始遇到这个问题的时候，束手无策，但今天我看到一句话，大意是：遇到不会的问题就google，自己遇到的问题，别人一定遇到过，所以我看了网上很多有关的文章，现在有那么一点思路，先记下来，然后再慢慢补充。 网
Fatal signal 11 (SIGSEGV) at 0x390955ae (code=1)
Gabby
03-16 4092
http://blog.youkuaiyun.com/gq414047080/article/details/9012691 关于如下debug无法看出究竟是哪出了问题。之前尝试各种方法，折腾了老半天都是没有结果。 F/libc    (  148): Fatal signal 11 (SIGSEGV) at 0x390955ae (code=1) I/ProtocalServi
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 3661 (ervice.Executor)
u012498660的专栏
04-02 1787
前言：当我们在android中的使用JNI下编译的.so库时，很有可能底层编译好的native method出现异常，而且底层并没有对这个异常进行捕捉，这样在我们APK上就是表现为退出程序，查看打印信息，出现的提示是：A/libc(2730): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 3661 (ervice.Executo
发生Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)问题
溯源守拙的博客
08-09 5879
问题：在验证某些功能时，启动camera auto DC模式成功，切换其它模式失败基本必现camera error，crash log如下： C015C0D 08-08 16:01:22.447 6408 6600 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xe375435c in tid 6600 (res_init), pid 6408 (provider@2.4-se) C015DB6 0...
A Fatal signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0 in tid 4542 (om.example.yili), pid 4542 (om.example.yili) 2025-04-24 22:12:32.154 4622-4622 DEBUG crash_dump64 A pid: 4542, tid: 4542, name: om.example.yili >>> com.example.yili <<< 2025-04-24 22:12:32.236 4622-4622 DEBUG crash_dump64 A #00 pc 00000000003f72be /data/app/com.example.yili-nGf79bU1jvxkpO2rcI16Pg==/lib/x86_64/libBaiduMapSDK_map_v7_6_4.so (_baidu_framework::CBaseLayer::CBaseLayer()+350) 2025-04-24 22:12:32.236 4622-4622 DEBUG crash_dump64 A #01 pc 00000000004b2cb5 /data/app/com.example.yili-nGf79bU1jvxkpO2rcI16Pg==/lib/x86_64/libBaiduMapSDK_map_v7_6_4.so 2025-04-24 22:12:32.236 4622-4622 DEBUG crash_dump64 A #02 pc 00000000004b2ba2 /data/app/com.example.yili-nGf79bU1jvxkpO2rcI16Pg==/lib/x86_64/libBaiduMapSDK_map
04-25
嗯，用户之前问过关于SIGSEGV错误的问题，特别是与BaiduMapSDK相关的。现在他们想查找在Android x86_64架构下使用BaiduMapSDK版本7.6.4时出现SIGSEGV错误的原因和解决方案，错误信息中提到了CBaseLayer和...
ART异常处理机制(1) - SIGSEGV信号的拦截和处理
大将军王虎剩的专栏
11-14 1万+
主要讲述 Android ART虚拟机的异常处理，StackOverflowError的检测和抛出原理，NullPointerException的检测和抛出原理等。
Linux内核进程,线程,进程组,会话组织模型以及进程管理
tugouxp的专栏
11-27 2923
唤醒睡眠状态任意的线程可以用wake_up_process,它可和唤醒处于深度睡眠状态的线程。结合最开始的图和代码，我们可以得到如下结论：1.kthead衍生的内核线程没有session pid,说人话就是所有的内核线程没有都没有操作控制台，不能通过控制台去操作控制。2.idle任务不会出现在for_each_process的处理循环中。3.每cpu_rq就绪队列中，不会将idle统计到nr_running中。
Fatal signal 11 (SIGSEGV) at 0x00000008 (code=1)应用闪退
文韬武略的专栏
09-01 5419
这个问题查了很久，you'yu https://forums.adobe.com/message/6243025
错误信息Fatal signal 11 (SIGSEGV) at 0x00000040 (code=1), thread 2736 (Thread-103)
难不难的博客
09-17 762
在用ffmpeg编码视频时报了这个错误，经过一步步排查，最后得知原因是io问题，在文件的都写时是否被赋予权限， 1.在AndroidMainfest是否允许对内存卡进行读写，权限如下<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> <uses-permission android:name="and
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)
runwuwushengxiyu的博客
07-08 180
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) 错误 解决方案(android-ndk)
JNI 编码中遇到 Fatal signal 11 (SIGSEGV)查看报错日志
燃烧那滴泪的专栏
09-14 1605
JNI 报错 SIGSEGV 通过信号量找出错误日志
Android:Fatal signal 11 (SIGSEGV), code 1, fault addr
L的博客
12-21 5万+
游戏出现死机，错误为： 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 p...
讲解Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
牛肉胡辣汤
12-10 1万+
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0是一个常见的C/C++程序运行时错误，它发生在程序试图访问无效的内存地址时。尽管解决这种错误可能会有一定的挑战，但通过仔细检查代码并采取防御性编程措施，我们可以最大程度地减少和解决这类错误。在实际应用场景中，你可能需要多方面地考虑代码中的可能错误，并进行适当的调试和修复。当我们运行这段代码时，它会导致Fatal signal 11错误，因为我们试图访问一个无效的内存地址。
详解 cn.sample.mnn.detect A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in t
牛肉胡辣汤
04-11 2415
在错误消息中，"cn.sample.mnn.detect" 表示应用程序的包名或相关类名，"A/libc" 表示与 Android 系统的 C 库 (libc) 相关。错误通常与内存访问相关，可能由空指针引用、对已释放内存的引用、内存越界访问或内存泄漏等因素引起。在解决这个错误时，你可以检查空指针引用、防止对已释放内存的引用、避免内存越界访问、检查内存泄漏、使用调试工具和日志记录等方法。这个错误通常与内存访问相关，并且是一个严重的错误，可能导致应用崩溃。方法中，我们释放了不再需要的内存，将。
Fatal signal 11 (SIGSEGV) 错误捕获并抛出给JAVA
明潮的BLOG
06-22 1万+
公司从人人网接收了经纬名片通，开始进行后续开发。该项目安卓的名片本地识别模块是调JNI的，最底层识别图片的部分暂时没有源代码。糟糕的是，该模块在部分机型上出现闪退，并报错：Fatal signal 11 (SIGSEGV) at .... (code=1)谷歌翻了十几页，都是讲怎么定位错误，怎么修改错误。可是底层的代码我没有啊，就算定位了也改不了。而且项目等着上线，就算后续要到源码也来不及了。所以...
Fatal signal 11 (SIGSEGV), code 2调试方法
有速度的空气的博客
11-19 1万+
JNI中用C语言引起的bug:Fatal signal 11 (SIGSEGV), code 2对于习惯Java的程序员, 调试C程序是一件很头痛的事, 尤其是这种bug, 出现一次整个App立刻崩掉, 并且还不给你打印函数调用栈, 压根不知道哪一行出了问题. 如果google或者百度这个错误的描述, 答案往往是指针使用了一个不可用的位置, 或者是数组越界, 对程序问题定位也没有有价值的帮助.Bug
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7a4a446040 in tid 5511
最新发布
07-23
### 修复 Android JNI 中 `while` 循环刷新 Surface 导致的 `SIGSEGV` 错误 在 Android 的 JNI 开发中，使用 `while` 徢环不断刷新数据并更新到 `Surface` 是常见的需求，例如在实时渲染或图像处理中。然而，不当的实现可能导致严重的运行时错误，如 `Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)`，即段错误，通常表示访问了未映射的内存地址。 #### 1. 检查 `ANativeWindow` 是否为空或已被释放 在 `while` 循环中访问 `ANativeWindow` 时，必须确保其不为空且未被释放。如果在 `Surface` 销毁后仍然尝试绘制，将导致非法内存访问。 ```cpp while (isRunning) { if (window == nullptr) continue; ANativeWindow_Buffer buffer; if (ANativeWindow_lock(window, &buffer, nullptr) == 0) { // 更新帧数据 ANativeWindow_unlockAndPost(window); } } ``` 在 `Surface` 被销毁时（如调用 `surfaceDestroyed`），应立即释放 `ANativeWindow` 并终止线程。 #### 2. 确保线程安全和同步机制 JNI 中的渲染线程与 Java 层的 UI 线程是分离的，必须确保线程间的数据访问是同步的。例如，当 `Surface` 被销毁时，应通过标志位 `isRunning` 通知渲染线程退出循环，避免访问已释放的资源[^2]。 ```cpp bool isRunning = false; extern "C" JNIEXPORT void JNICALL Java_edu_example_NativeRenderer_stopRendering(JNIEnv* env, jobject /* this */) { isRunning = false; if (window) { ANativeWindow_release(window); window = nullptr; } } ``` #### 3. 使用 `Handler` 或主线程调用 JNI 方法 如果某些 JNI 方法需要操作 UI 或 `Surface`，应通过 `Handler` 在主线程中调用，避免在子线程中直接操作 `Surface`，否则可能因线程调度不一致导致内存访问异常。 ```java new Handler(Looper.getMainLooper()).post(() -> { startRendering(holder); }); ``` #### 4. 检查权限问题 某些操作（如从 SD 卡读取图像数据）可能需要动态权限申请。如果应用未请求 `READ_EXTERNAL_STORAGE` 或 `WRITE_EXTERNAL_STORAGE`，可能导致访问非法内存地址而崩溃[^1]。 ```java if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.READ_EXTERNAL_STORAGE}, 1); } ``` #### 5. 使用 `addr2line` 定位崩溃地址 当发生 `SIGSEGV` 错误时，可通过 `addr2line` 工具定位具体出错的代码位置，帮助排查非法内存访问问题[^4]。 ```bash arm-linux-androideabi-addr2line -C -f -e libnative-lib.so 00026877 ``` #### 6. 避免资源竞争和重复释放 确保 `ANativeWindow_fromSurface` 和 `ANativeWindow_release` 成对调用，防止重复释放或多次绑定同一个 `Surface`，这可能导致内存访问冲突。 --- ### 示例代码：修复后的 JNI 渲染线程逻辑 ```cpp #include <jni.h> #include <android/native_window.h> #include <android/native_window_jni.h> #include <pthread.h> #include <unistd.h> ANativeWindow* window = nullptr; bool isRunning = false; void* renderThread(void*) { while (isRunning) { if (window == nullptr) { usleep(10000); // 等待Surface可用 continue; } ANativeWindow_Buffer buffer; if (ANativeWindow_lock(window, &buffer, nullptr) == 0) { // 填充像素数据 uint32_t* pixels = static_cast<uint32_t*>(buffer.bits); int pixelCount = buffer.width * buffer.height; for (int i = 0; i < pixelCount; ++i) { pixels[i] = 0xFF00FF00; // 绿色 } ANativeWindow_unlockAndPost(window); } else { // 锁定失败，短暂休眠避免CPU占用过高 usleep(10000); } usleep(33000); // 控制帧率 } return nullptr; } extern "C" JNIEXPORT void JNICALL Java_edu_example_NativeRenderer_startRendering(JNIEnv* env, jobject /* this */, jobject surface) { if (window != nullptr) { ANativeWindow_release(window); } window = ANativeWindow_fromSurface(env, surface); isRunning = true; pthread_t thread; pthread_create(&thread, nullptr, renderThread, nullptr); } extern "C" JNIEXPORT void JNICALL Java_edu_example_NativeRenderer_stopRendering(JNIEnv* /* env */, jobject /* this */) { isRunning = false; if (window) { ANativeWindow_release(window); window = nullptr; } } ``` --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值