Android-jni(6)-常见错误异常

最新推荐文章于 2022-07-11 07:35:00 发布
最新推荐文章于 2022-07-11 07:35:00 发布
阅读量1w 收藏 25
点赞数 5
分类专栏： Android-NDK 文章标签： Android NDK 常见错误异常
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ddxxii/article/details/84781110
版权

NDK异常信息一般有三个要素：

  1. 信号
  2. 调用栈信息
  3. 寄存器信息

比如一下是一个空指针的错误信息：

 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 31286 (shixin.ndkdemo)
I/crash_dump32: obtaining output fd from tombstoned
I//system/bin/tombstoned: received crash request for pid 31286
I/crash_dump32: performing dump of process 31286 (target tid = 31286)
A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.0.0/OSR1.170901.056/4497355:userdebug/dev-keys'
A/DEBUG: Revision: '0'
A/DEBUG: ABI: 'x86'
A/DEBUG: pid: 31286, tid: 31286, name: shixin.ndkdemo  >>> shixin.ndkdemo <<<
A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
A/DEBUG: Cause: null pointer dereference
A/DEBUG:     eax 9014fe0c  ebx 9014fe0c  ecx 00000000  edx afd29310
A/DEBUG:     esi 90484b65  edi bfa41468
A/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 0000003b  xss 0000007b
A/DEBUG:     eip 9010fc94  ebp bfa41278  esp bfa41230  flags 00010286
A/DEBUG: backtrace:
A/DEBUG:     #00 pc 00008c94  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (_Z9crashNullv+36)
A/DEBUG:     #01 pc 00008dda  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (Java_shixin_ndkdemo_MainActivity_testCrash+42)
A/DEBUG:     #02 pc 000086f8  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/oat/x86/base.odex (offset 0x8000)
A/DEBUG:     #03 pc 00059fff  [anon:libc_malloc:afd00000]
A/DEBUG:     #04 pc 0008ef27  /dev/ashmem/dalvik-main space (region space) (deleted)
A/DEBUG:     #05 pc 8bc3b28f  <unknown>
A/DEBUG:     #06 pc 80c1c541  <unknown>
A/DEBUG:     #07 pc 0d3fffff  /dev/ashmem/dalvik-main space (region space) (deleted)
E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_00

对应的三个要素：

  1. 信号：这里的signal 11 (SIGSEGV)，每个错误信息有对应的值，比如这个是11
  2. 调用栈：
//堆栈
A/DEBUG: backtrace:
            //错误起始地址依次往下
A/DEBUG:     #00 pc 00008c94  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (_Z9crashNullv+36)
A/DEBUG:     #01 pc 00008dda  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (Java_shixin_ndkdemo_MainActivity_testCrash+42)
A/DEBUG:     #02 pc 000086f8  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/oat/x86/base.odex (offset 0x8000)
A/DEBUG:     #03 pc 00059fff  [anon:libc_malloc:afd00000]
A/DEBUG:     #04 pc 0008ef27  /dev/ashmem/dalvik-main space (region space) (deleted)
A/DEBUG:     #05 pc 8bc3b28f  <unknown>
A/DEBUG:     #06 pc 80c1c541  <unknown>
A/DEBUG:     #07 pc 0d3fffff  /dev/ashmem/dalvik-main space (region space) (deleted)
  1. 寄存器信息：
    //空指针引用错误原因，很多时候没有这个
A/DEBUG: Cause: null pointer dereference
            //寄存器信息地址
A/DEBUG:     eax 9014fe0c  ebx 9014fe0c  ecx 00000000  edx afd29310
A/DEBUG:     esi 90484b65  edi bfa41468
A/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 0000003b  xss 0000007b
A/DEBUG:     eip 9010fc94  ebp bfa41278  esp bfa41230  flags 00010286

接下来记录下常见的异常：

一. 空指针：

说明：

  1. 指针引用不能访问地址
  2. 指针为空

空指针是很容易出现的一种bug，但是它也很容易被发现和修复。比如以下代码就会报空指针：

  • 操作不能访问地址：
/**
 * 空指针
 */
void crashNull() {
    //0为其实地址，是不可读写的，会立即崩溃
    int *p = 0;
    *p = 1;
    LOGE("p:%d", *p);
}
  • 空指针访问：
/**
 * 空指针
 */
void crashNull() {
    int *p = NULL;
    *p = 1;
    LOGE("p:%d", *p);
}

运行崩溃,异常日志:

 A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 31286 (shixin.ndkdemo)
I/crash_dump32: obtaining output fd from tombstoned
I//system/bin/tombstoned: received crash request for pid 31286
I/crash_dump32: performing dump of process 31286 (target tid = 31286)
A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.0.0/OSR1.170901.056/4497355:userdebug/dev-keys'
A/DEBUG: Revision: '0'
A/DEBUG: ABI: 'x86'
A/DEBUG: pid: 31286, tid: 31286, name: shixin.ndkdemo  >>> shixin.ndkdemo <<<
A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
A/DEBUG: Cause: null pointer dereference
A/DEBUG:     eax 9014fe0c  ebx 9014fe0c  ecx 00000000  edx afd29310
A/DEBUG:     esi 90484b65  edi bfa41468
A/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 0000003b  xss 0000007b
A/DEBUG:     eip 9010fc94  ebp bfa41278  esp bfa41230  flags 00010286
A/DEBUG: backtrace:
A/DEBUG:     #00 pc 00008c94  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (_Z9crashNullv+36)
A/DEBUG:     #01 pc 00008dda  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/lib/x86/libmy_native_lib.so (Java_shixin_ndkdemo_MainActivity_testCrash+42)
A/DEBUG:     #02 pc 000086f8  /data/app/shixin.ndkdemo-1hGHzLT4mUe7NO7XJcyfdg==/oat/x86/base.odex (offset 0x8000)
A/DEBUG:     #03 pc 00059fff  [anon:libc_malloc:afd00000]
A/DEBUG:     #04 pc 0008ef27  /dev/ashmem/dalvik-main space (region space) (deleted)
A/DEBUG:     #05 pc 8bc3b28f  <unknown>
A/DEBUG:     #06 pc 80c1c541  <unknown>
A/DEBUG:     #07 pc 0d3fffff  /dev/ashmem/dalvik-main space (region space) (deleted)
E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_00
解决方案：使用前加非空判断
//判断不为空再进行执行
if (!*p == NULL) {
        *p = 1;
        LOGE("p:%d", *p);
    }

注意：该解决方案针对与指针为空的情况，如果指针是第一种不能访问地址，那么判空也是不行的，不过第一种我想大家也很容易就能发现

二. 野指针:

说明：

指针指向无效地址：

  1. 如果该地址是不可读不可写，那么立马会遇到crash（内核给进程发送错误信息SIGSEGV）
  2. 如果该指针的地址可写，那么可能等一会才会出现崩溃(其他指针修改了这一块地址)，这时候查看调用栈和野指针所在代码部分可能根本没有关联。
/**
 * 野指针
 */
void wildPointer() {
    //开始没有初始化
    int *p;
    //中途使用
    *p = 1;
}

这种情况不会立马crash，但是是很不安全的，说不定在之后某一时刻就崩溃了

解决方案：
  1. 指针变量一定要初始化，特别是结构体或类中的成员变量的指针
  2. 使用完后，在不用的情况，尽量执为NULL(如果别的地方也有指针指向这段内存就不好解决)

例如：

int o;
    //初始化,指向给o的地址
    int *p = &o;
    //中途使用赋值，就是给o赋值了
    *p = 1;
    LOGE("o:%d", *p);
    //用完后指向NULL
    *p = NULL;

注意： 野指针造成的内存破坏，很难发现，一般需要专业内存检测工具，才能发现这一类的bug

三. 数组越界

说明：

数组越界和野指针有点像，访问了其他地址，如果访问地址是不可读写的，那么立马会Crash(内核给进程发送错误信号SIGSEGV)，如果是可读写的地址，修改了该地址内存，造成内存破坏，那么有可能等会在别的地方发生Crash。

解决方案:
  1. 所有数组遍历的循环，都要加上越界判断
  2. 用下标访问数组的时候，要判断是否越界
  3. 通过代码分析工具可以发现绝大部分数组越界问题
 int data[10];
    //越界赋值，先判断下size
    int sizeData = sizeof(data);
    for (int i = 0; i < 17; ++i) {
        if (sizeData <= 17) {
            data[i] = 666;
        }
    }
    LOGE("data[11]:%d", data[11]);

PS：在笔者四处查询，貌似不同的编译器对此问题也有的有处理，会报错等，C++也有运行时报错的情况(有的也说不报错，尴尬)。不管它怎么，自己使用的时候一定要注意判断下，数组越界这个需要重视，因为内存连续的原因，如果一越界了，那么很有可能就将这个数组之后定义的一个变量值给修改了。

四. 内存泄漏

说明：

c与c++没有像java那样自动回收的GC机制，所以使用完需要手动释放，如果没有释放，就造成内存泄漏。

比如：

jstring str = env->NewStringUTF("哈哈哈哈");
    if (str == NULL) {
        LOGE("str is null");
        return;
    }
    const char *stringChar = env->GetStringUTFChars(str, 0);
    LOGE("str:%s", stringChar);
解决方案：
  1. 用完后进行释放

例如：

jstring str = env->NewStringUTF("哈哈哈哈");
    if (str == NULL) {
        LOGE("str is null");
        return;
    }
    const char *stringChar = env->GetStringUTFChars(str, 0);
    LOGE("str:%s", stringChar);

    //用完后进行释放
    env->DeleteLocalRef(str);
    env->ReleaseStringUTFChars(str,stringChar);
五. 堆栈溢出

说明：

与java的堆栈溢出异常一样，jni中一样有堆栈溢出异常，比如超过堆大小，或超过栈深度时候爆出。

解决方案：
  1. 对于堆溢出，在做好释放操作，只要做好避免内存泄漏，合理分配内存使用，一般不会出，现在堆大小还是挺大的
  2. 对于栈溢出，做递归的时候重复调用方法的时候，考虑好栈的深度，适时的做好切换操作，避免栈溢出
六. 格式化参数错误
  1. 需要格式化参数类型的时候，有可能出现错误

比如：

int b=0;
    LOGE("b:%s", b);

异常日志和空指针挺像的

A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x1 in tid 4406 (shixin.ndkdemo)
I/crash_dump32: obtaining output fd from tombstoned
I//system/bin/tombstoned: received crash request for pid 4406
I/crash_dump32: performing dump of process 4406 (target tid = 4406)
A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.0.0/OSR1.170901.056/4497355:userdebug/dev-keys'
A/DEBUG: Revision: '0'
A/DEBUG: ABI: 'x86'
A/DEBUG: pid: 4406, tid: 4406, name: shixin.ndkdemo  >>> shixin.ndkdemo <<<
A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1
A/DEBUG: Cause: null pointer dereference
解决方案
  1. 在书写输出格式和参数时，要做到参数个数和类型都要与输出格式一致。
  2. 在GCC的编译选项中加入-wformat，让GCC在编译时检测出此类错误。
六. 除以0

分母为0的这种情况，会很快Crash，一般都是在实际运行环境中还有可能出现，所以编码习惯的时候应该尽量习惯性去判断下

示例代码：

/**
 * 除以0
 */
void zeroDiv() {
    int a = 1;
    int b = a / 0; //整数除以0，产生SIGFPE信号，导致Crash
    LOGE("b:%d", b);
}

崩溃日志：

A/libc: Fatal signal 8 (SIGFPE), code 1, fault addr 0x8ff0ef12 in tid 3804 (shixin.ndkdemo)
I/crash_dump32: obtaining output fd from tombstoned
I//system/bin/tombstoned: received crash request for pid 3804
I/crash_dump32: performing dump of process 3804 (target tid = 3804)
A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:8.0.0/OSR1.170901.056/4497355:userdebug/dev-keys'
A/DEBUG: Revision: '0'
A/DEBUG: ABI: 'x86'
A/DEBUG: pid: 3804, tid: 3804, name: shixin.ndkdemo  >>> shixin.ndkdemo <<<
A/DEBUG: signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0x8ff0ef12
A/DEBUG:     eax 00000001  ebx 00000001  ecx 00000004  edx 00000000
A/DEBUG:     esi 8ff48171  edi 00000000
A/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 0000003b  xss 0000007b
A/DEBUG:     eip 8ff0ef12  ebp bfa41278  esp bfa41230  flags 00010246
A/DEBUG: backtrace:
A/DEBUG:     #00 pc 00008f12  /data/app/shixin.ndkdemo-QvqFUNT_8-bffRNbIoelFQ==/lib/x86/libmy_native_lib.so (_Z7zeroDivv+66)
A/DEBUG:     #01 pc 00008f7a  /data/app/shixin.ndkdemo-QvqFUNT_8-bffRNbIoelFQ==/lib/x86/libmy_native_lib.so (Java_shixin_ndkdemo_MainActivity_testCrash+42)
A/DEBUG:     #02 pc 000096f8  /data/app/shixin.ndkdemo-QvqFUNT_8-bffRNbIoelFQ==/oat/x86/base.odex (offset 0x9000)
A/DEBUG:     #03 pc 00059fff  [anon:libc_malloc:afd00000]
A/DEBUG:     #04 pc 00052727  /dev/ashmem/dalvik-main space (region space) (deleted)
A/DEBUG:     #05 pc 8bc3b28f  <unknown>
A/DEBUG:     #06 pc 80c1c541  <unknown>
A/DEBUG:     #07 pc 0d3fffff  /dev/ashmem/dalvik-main space (region space) (deleted)
解决方案
  1. 在有除法的时候，判断下分母为0的情况

例如：

    int a = 1;
    //将分母给拿出来判断，运行时很可能是某个计算值
    int c = 0;
    int b;
    if (c != 0) {
        //判断下
        b = a / c;
    } else {
        b = a;
    }
    LOGE("b:%d", b);

感谢(http://www.droidsec.cn/常见android-native崩溃及错误原因/)，这位作者总结的很好，学习了。

Joney小鬼
关注
专栏目录
Android进阶-原生c、c++代码bug定位的方法
王涛的博客
08-08 1338
一、崩溃转储 参考android官网： https://developer.android.google.cn/ndk/guides/ndk-stack?hl=zh-cn https://source.android.google.cn/devices/tech/debug https://source.android.google.cn/devices/tech/debug/native-cra...
android dmp文件解析,用minidump_stackwalk分析dmp文件失败
weixin_34858011的博客
05-29 1133
我使用的是macOS 10.13.6我成功把crash文件抓取到本地并且本地编译了minidump_stackwalk，但是使用工具的时候，terminal会报很多错误，用google搜索也找不到答案➜ processor git:(5467393a) ✗ ./minidump_stackwalk crashDump/e9c42b5d-8a0f-480d-d086608e-54b9110c.dm...
怎样分析crash dump(内存错误)
u011279649的专栏
02-13 1万+
Memory错误 在内核中，内存是以cache的形式组织的，每个对象类型对应一个cache，如（inod_cache,dentry_cache, buffer_head,vm_area_strutct等）；每个cache包含多个slab(slab由一个或多个页组成，这些页物理上是连续的)；每个slab包含多个初始化的对象。 Cache可以分为两类【kmalloc使用的和其他】，当然他们是用
Android笔记 跟踪c++代码报错
reasonboy的博客
10-26 1854
问题 用logcat抓取到报错如下 10-26 15:14:46.777 3174 3174 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone 10-26 15:14:46.778 1810 1810 I /system/bin/tombstoned: received cr...
[Python] Native Crash Addr2line 自动解析Tombstone文件脚本
TaylorPotter的博客
01-17 1914
[Python] Native Crash Addr2line 自动解析Tombstone文件脚本 使用方法 1.解析单个tombstone文件： python ./as_tomba.py tombstone_file_path symbol_root_path 在tombstone_file_path目录下生成 tombstone文件名_pid_pname.out 的解析之后文件 2.批量解析...
linux编译的so android闪退,android so库导致的闪退及tombstone分析
weixin_35537968的博客
05-11 1426
android中有3种crash情况：未捕获的异常、ANR和闪退。未捕获的异常一般用crash文件就可以记录异常信息，而ANR无响应表现就是界面卡着无法响应用户操作，而闪退则是整个app瞬间退出，个人感觉对用户造成的体验最差。闪退一般是由于调用so库出错导致，像类似非法地址访问等。闪退发生时在logcat中将日志过滤条件选为“No Filters”就可以看到完整的闪退日志，或者叫tombstone...
cpp-JNI封装的底层加密实现可跨平台使用
08-16
描述中的"JNI封装的底层加密实现，可跨平台使用"进一步强调了这个项目的目标：通过JNI将加密算法封装起来，确保无论是在Windows、Linux还是Android等不同操作系统上，都能稳定地提供加密服务。这通常涉及到对底层...
安卓逆向_15（ 一 ） --- JNI 和 NDK
墨鱼菜鸡
07-11 611
From：较详细的介绍JNI：https://blog.csdn.net/lizhifa2011/article/details/21021177 From：https://www.jb51.net/article/126111.htm NDK官方文档：https://developer.android.google.cn/training/art...
详解AndroidStudio JNI +Gradle3.0以上JNI爬坑之旅
08-28
- 注意处理异常，因为JNI调用中的错误处理相对复杂，需要仔细处理可能出现的异常情况。 通过以上步骤，开发者可以成功地在Android Studio中使用JNI和Gradle 3.0以上的版本进行本地化开发。尽管这个过程中可能会...
android_jni操作指南.zip
最新发布
04-08
"android_jni操作指南.pdf"和"说明.txt"很可能是详细的教程文档，涵盖了JNI的使用步骤、示例代码以及常见问题解答。通过阅读这些资料，开发者可以深入学习如何在实际项目中运用JNI技术。 总结来说，JNI是Android...
Android-NDK开发Crash错误定位，android适配方案
flutter001的博客
12-31 660
01-01 17:59:38.586: I/DEBUG(253): r8 75226d08 r9 00000000 sl 417c5c38 fp bedbf134 01-01 17:59:38.586: I/DEBUG(253): ip 41705910 sp bedbf0f0 lr 4012e169 pc 4013d10c cpsr 000f0010 // 省略部份日志 。。。。。。 01-01 17:59:38.596: I/DEBUG(253): backtrace: 0
Android Studio 简单介绍和使用问题小结
热门推荐
light_sky的专栏
05-17 5万+
google在2013的I/O开发者大会上引入的该开发工具。现在是0.5.8版本。 现在github的很多项目都使用了Android Studio开发，所以如果你还用Eclipse，就需要把整个项目拆分， 然后在工程中include依赖包，是非常费事的，有时候弄了半天还不一定能成功导入。而且Android开发者工具的未来的趋势一定也是转向Android Studio。 所以种种原因，不得不学
linux 强制回收fd,深入学习fd泄露问题
weixin_33034651的博客
05-14 1231
最近遇到一个应用闪退的问题，开始发现问题时没有找到明显的问题复现步骤，单独操作应用里的所有功能都没有发生该问题，而一旦进行煲机测试半小时后出现了。光从应用层的log也分析不出问题的原因来，这个问题拖了很长一段时间，真是惭愧！煲机的业务逻辑是通过PC程序循环发送指令到车机板子上，控制车机上的测试程序，调起测试case执行硬件模块的测试。问题分析分析该问题发生时的log文件，与我的应用有关的log内容...
ART虚拟机的一个缺陷[Java 8 特性]
大将军王虎剩的专栏
01-18 3150
1.问题背景：[Android Version]：8.0[问题] CTS：tck.java.time.chrono.TCKChronoLocalDateTime#test_from_TemporalAccessor[CTS CMD]：run cts -m CtsLibcoreOjTestCases -t tck.java.time.chrono.TCKChronoLocalDateTime#tes
Java 创建线程的3种方式以及它们的优缺点
qq_43357394的博客
11-18 1682
文章目录1.创建线程的三种方法2.三种方式的优缺点①采用继承Thread类方式：②采用实现Runnable接口方式：③Runnable和Callable的区别：④start（）和run（）的区别3.参考链接 1.创建线程的三种方法 继承Thread类，重写run(); 实现Runnable接口，重写run(); 实现Callable接口，重写call(); 创建线程池创建 2.三种方式的优缺点 ①采用继承Thread类方式： （1）优点：编写简单，如果需要访问当前线程，无需使用Thread.curren
android的崩溃报告(crash dump)
john_crash的专栏
07-14 5265
ACRA (Application Crash Report For Android)就是为了解决android 应用程序崩溃以后的发送报告的问题。 你能在https://github.com/ACRA找到源代码。 其中https://github.com/ACRA/acra/wiki/BasicSetup页详细的介绍了使用方法。 注意ACRA仅能俘获java的异常，它不能俘获native c
使用 Crash 工具分析 Linux dump 文件
技术风向标
04-05 2362
前言 Linux 内核（以下简称内核）是一个不与特定进程相关的功能集合，内核的代码很难轻易的在调试器中执行和跟踪。开发者认为，内核如果发生了错误，就不应该继续运行。因此内核发生错误时，它的行为通常被设定为系统崩溃，机器重启。基于动态存储器的电气特性，机器重启后，上次错误发生时的现场会遭到破坏，这使得查找内核的错误变得异常困难。 内核社区和一些商业公司为此开发了很多种调试技术和工具，希望...
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值