文档章节

Android NDK开发Crash错误定位

shzwork
 shzwork
发布于 06/25 23:49
字数 2910
阅读 5
收藏 0

Android开发中,程序Crash分三种情况:未捕获的异常、ANR(Application Not Responding)和闪退(NDK引发错误)。其中未捕获的异常根据logcat打印的堆栈信息很容易定位错误。ANR错误也好查,Android规定,应用与用户进行交互时,如果5秒内没有响应用户的操作,则会引发ANR错误,并弹出一个系统提示框,让用户选择继续等待或立即关闭程序。并会在/data/anr目录下生成一个traces.txt文件,记录系统产生anr异常的堆栈和线程信息。如果是闪退,这问题比较难查,通常是项目中用到了NDK引发某类致命的错误导致闪退。因为NDK是使用C/C++来进行开发,熟悉C/C++的程序员都知道,指针和内存管理是最重要也是最容易出问题的地方,稍有不慎就会遇到诸如内存地址访问错误、使用野针对、内存泄露、堆栈溢出、初始化错误、类型转换错误、数字除0等常见的问题,导致最后都是同一个结果:程序崩溃。不会像在Java层产生的异常时弹出“xxx程序无响应,是否立即关闭”之类的提示框。当发生NDK错误后,logcat打印出来的那堆日志根据看不懂,更别想从日志当中定位错误的根源,让我时常有点抓狂,火冒三丈,喝多少加多宝都不管用。当时尝试过在各个jni函数中打印日志来跟踪问题,那效率实在是太低了,而且还定位不到问题。还好老天有眼,让我找到了NDK提供的几款调试工具,能够精确的定位到产生错误的根源。

       NDK安装包中提供了三个调试工具:addr2line、objdump和ndk-stack,其中ndk-stack放在$NDK_HOME目录下,与ndk-build同级目录。addr2line和objdump在ndk的交叉编译器工具链目录下,下面是我本机NDK交叉编译器工具链的目录结构:

从上图的目录结构中可以看出来,NDK针对不同的CPU架构实现了多套相同的工具。所以在选择addr2line和objdump工具的时候,要根据你目标机器的CPU架构来选择。如果是arm架构,选择arm-linux-androidabi-4.6/4.8(一般选择高版本)。x86架构,选择x86-4.6/4.8。mipsel架构,选择mipsel-linux-android-4.6/4.8。如果不知道目标机器的CPU架构,把手机连上电脑,用adb shell cat /proc/cpuinfo可以查看手机的CPU信息。下图是我本机的arm架构工具链目录结构:

 

下面通过NDK自带的例子hello-jni项目来演示一下如何精确的定位错误

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. #include <string.h>  
  2. #include <jni.h>  
  3. // hell-jni.c  
  4. #ifdef __cplusplus  
  5. extern "C" {  
  6. #endif  
  7.     void willCrash()  
  8.     {  
  9.         int i = 10;  
  10.         int y = i / 0;  
  11.     }  
  12.   
  13.     JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)  
  14.     {  
  15.         willCrash();  
  16.         return JNI_VERSION_1_4;  
  17.     }  
  18.   
  19.     jstring  
  20.     Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,  
  21.                                                       jobject thiz )  
  22.     {  
  23.     // 此处省略实现逻辑。。。  
  24.     }  
  25.   
  26. #ifdef __cplusplus  
  27. }  
  28. #endif  

第7行定义了一个willCrash函数,函数中有一个除0的非法操作,会造成程序崩溃。第13行JNI_OnLoad函数中调用了willCrash,这个函数会在Java加载完.so文件之后回调,也就是说程序一启动就会崩溃。下面是运行程序后打印的log:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. 01-01 17:59:38.246: D/dalvikvm(20794): Late-enabling CheckJNI  
  2. 01-01 17:59:38.246: I/ActivityManager(1185):   
  3. Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid=20794 uid=10351 gids={50351, 1028, 1015}  
  4. 01-01 17:59:38.296: I/dalvikvm(20794): Enabling JNI app bug workarounds for target SDK version 3...  
  5. 01-01 17:59:38.366: D/dalvikvm(20794): Trying to load lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58  
  6. 01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58  
  7. 01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=-6), thread 20794 (xample.hellojni)  
  8. 01-01 17:59:38.476: I/DEBUG(253): pid: 20794, tid: 20794, name: xample.hellojni  >>> com.example.hellojni <<<  
  9. 01-01 17:59:38.476: I/DEBUG(253): signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000513a  
  10. 01-01 17:59:38.586: I/DEBUG(253):     r0 00000000  r1 0000513a  r2 00000008  r3 00000000  
  11. 01-01 17:59:38.586: I/DEBUG(253):     r4 00000008  r5 0000000d  r6 0000513a  r7 0000010c  
  12. 01-01 17:59:38.586: I/DEBUG(253):     r8 75226d08  r9 00000000  sl 417c5c38  fp bedbf134  
  13. 01-01 17:59:38.586: I/DEBUG(253):     ip 41705910  sp bedbf0f0  lr 4012e169  pc 4013d10c  cpsr 000f0010  
  14.                                             // 省略部份日志 。。。。。。  
  15. 01-01 17:59:38.596: I/DEBUG(253): backtrace:  
  16. 01-01 17:59:38.596: I/DEBUG(253):     #00  pc 0002210c  /system/lib/libc.so (tgkill+12)  
  17. 01-01 17:59:38.596: I/DEBUG(253):     #01  pc 00013165  /system/lib/libc.so (pthread_kill+48)  
  18. 01-01 17:59:38.596: I/DEBUG(253):     #02  pc 00013379  /system/lib/libc.so (raise+10)  
  19. 01-01 17:59:38.596: I/DEBUG(253):     #03  pc 00000e80  /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8)  
  20. 01-01 17:59:38.596: I/DEBUG(253):     #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)  
  21. 01-01 17:59:38.596: I/DEBUG(253):     #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)  
  22. 01-01 17:59:38.596: I/DEBUG(253):     #06  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)  
  23. 01-01 17:59:38.596: I/DEBUG(253):     #07  pc 0006a62d  /system/lib/libdvm.so  
  24. 01-01 17:59:38.596: I/DEBUG(253):          // 省略部份日志 。。。。。。  
  25. 01-01 17:59:38.596: I/DEBUG(253): stack:  
  26. 01-01 17:59:38.596: I/DEBUG(253):          bedbf0b0  71b17034  /system/lib/libsechook.so  
  27. 01-01 17:59:38.596: I/DEBUG(253):          bedbf0b4  7521ce28    
  28. 01-01 17:59:38.596: I/DEBUG(253):          bedbf0b8  71b17030  /system/lib/libsechook.so  
  29. 01-01 17:59:38.596: I/DEBUG(253):          bedbf0bc  4012c3cf  /system/lib/libc.so (dlfree+50)  
  30. 01-01 17:59:38.596: I/DEBUG(253):          bedbf0c0  40165000  /system/lib/libc.so  
  31. 01-01 17:59:38.596: I/DEBUG(253):          // 省略部份日志 。。。。。。  
  32. 01-01 17:59:38.736: W/ActivityManager(1185):   Force finishing activity com.example.hellojni/.HelloJni  

日志分析:

第3行开始启动应用,第5行尝试加载应用数据目录下的so,第6行在加载so文件的时候产生了一个致命的错误,第7行的Fatal signal 8提示这是一个致命的错误,这个信号是由linux内核发出来的,信号8的意思是浮点数运算异常,应该是在willCrash函数中做除0操作所产生的。下面重点看第15行backtrace的日志,backtrace日志可以看作是JNI调用的堆栈信息,以“#两位数字 pc”开头的都是backtrace日志。注意看第20行和21行,是我们自己编译的so文件和定义的两个函数,在这里引发了异常,导致程序崩溃

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. 01-01 17:59:38.596: I/DEBUG(253):     #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)  
  2. 01-01 17:59:38.596: I/DEBUG(253):     #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)  

开始有些眉目了,但具体崩在这两个函数的哪个位置,我们是不确定的,如果函数代码比较少还好查,如果比较复杂的话,查起来也费劲。这时候就需要靠NDK为我们提供的工具来精确定位了。在这之前,我们先记录下让程序崩溃的汇编指令地址,willCrash:00000cf4,JNI_OnLoad:00000d1c

方式1:使用arm-linux-androideabi-addr2line  定位出错位置
以arm架构的CPU为例,执行如下命令:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. /Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line -e /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so 00000cf4 00000d1c  

-e:指定so文件路径

0000cf4 0000d1c:出错的汇编指令地址

结果如下:

是不是惊喜的看到我们想要的结果了,分别在hello-jni.c的10和15行的出的错,再回去看看hello-jni.c的源码,15行的Jni_OnLoad函内调用了willCrash函数,第10行做了除0的操作引发的crash。

方式2:使用arm-linux-androideabi-objdump  定位出错的函数信息

在第一种方式中,通过addr2lin已经获取到了代码出错的位置,但是不知道函数的上下文信息,显得有点不是那么的“完美”,对于追求极致的我来说,这显然是不够的,下面我们来看一下怎么来定位函数的信息。
首先使用如下命令导出so的函数表信息:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. /Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -S -D /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so > Users/yangxin/Desktop/dump.log  

在生成的asm文件中,找出我们开始定位到的那两个出错的汇编指令地址(在文件中搜索cf4或willCrash可以找到),如下图所示:

通过这种方式,也可以查出这两个出错的指针地址分别位于哪个函数中。

方式3:ndk-stack

如果你觉得上面的方法太麻烦的话,ndk-stack可以帮你减轻操作步聚,直接定位到代码出错的位置。

实时分析日志:

使用adb获取logcat的日志,并通过管道输出给ndk-stack分析,并指定包含符号表的so文件位置。如果程序包含多种CPU架构,需要根据手机的CPU类型,来选择不同的CPU架构目录。以armv7架构为例,执行如下命令:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a  

当程序发生crash时,会输出如下信息:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. pid: 22654, tid: 22654, name: xample.hellojni  >>> com.example.hellojni <<<  
  2. signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000587e  
  3. Stack frame #00  pc 0002210c  /system/lib/libc.so (tgkill+12)  
  4. Stack frame #01  pc 00013165  /system/lib/libc.so (pthread_kill+48)  
  5. Stack frame #02  pc 00013379  /system/lib/libc.so (raise+10)  
  6. Stack frame #03  pc 00000e80  /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8): Routine __aeabi_idiv0 at /s/ndk-toolchain/src/build/../gcc/gcc-4.6/libgcc/../gcc/config/arm/lib1funcs.asm:1270  
  7. Stack frame #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32): Routine willCrash at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:10  
  8. Stack frame #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:15  
  9. Stack frame #06  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)  
  10. Stack frame #07  pc 0006a62d  /system/lib/libdvm.so  

第7行和第8行分别打印出了在源文件中出错的位置,和addr2line得到的结果一样。

先获取日志再分析:
这种方式和上面的方法差不多,只是获取log的来源不一样。适用于应用或游戏给测试部们测试的时候,测试人员发现crash,用adb logcat保存日志文件,然后发给程序员通过ndk-stack命令分析。操作流程如下:

[cpp] view plain copy

 在CODE上查看代码片派生到我的代码片

  1. adb logcat > crash.log  
  2. ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log  

得到的结果和上面的方式是一样的。

==================================

我们如何把一个java中的String改写为c中的char*

 

链接地址

/**
 *Jstring2CStr 把java中的string 转化成 c中的char数组.
 *jstring   jstr 要被转化的java string
 *char*  代表的是字符串数组名称(字符串数组的首地址)
 */
char*   Jstring2CStr(JNIEnv*   env,   jstring   jstr)
{
     char*   rtn   =   NULL;
     jclass   clsstring   =   (*env)->FindClass(env,"java/lang/String");//寻找 java里面String.class
     jstring   strencode   =   (*env)->NewStringUTF(env,"GB2312");//创建java字符串 "gb2312"
     jmethodID   mid   =   (*env)->GetMethodID(env,clsstring,   "getBytes",   "(Ljava/lang/String;)[B");//寻找到java String getbytes();
     jbyteArray   barr=   (jbyteArray)(*env)->CallObjectMethod(env,jstr,mid,strencode); // String .getByte("GB2312");
     jsize   alen   =   (*env)->GetArrayLength(env,barr); //获取长度
     jbyte*   ba   =   (*env)->GetByteArrayElements(env,barr,JNI_FALSE); //jbyteArray转为jbyte* 

     if(alen   >   0)
     {
      rtn   =   (char*)malloc(alen+1);         //"\0"
      memcpy(rtn,ba,alen);
      rtn[alen]=0;
     }
     (*env)->ReleaseByteArrayElements(env,barr,ba,0);  //释放掉
     return rtn;
}

 

 

===============================

H264 安卓编码

 

还推荐一个项目,该项目实现了编码后的数据存为本地.h264文件,方便分析,本人Fork的git地址: https://github.com/eterrao/MediaCodecEncodeH264.git

原作者git地址: https://github.com/sszhangpengfei/MediaCodecEncodeH264.git

(在此感谢拥有开源共享精神的各位朋友,因为你们我才能在学习和成长的路上少了很多坑!)

实际上MediaCodec的实现步骤基本都大同小异,但是请注意在API20以后编码器数据处理的机制有所改变,官方给出的建议如下:

链接: developer.android.com/reference/android/media/MediaCodec.html

本文转载自:https://blog.csdn.net/bingqingsuimeng/article/details/51364854

shzwork
粉丝 15
博文 819
码字总数 10675
作品 0
厦门
私信 提问
如何定位Android NDK开发中遇到的错误

正式开始这个话题之前,先简单介绍一下什么是NDK和JNI,部分内容来自网络 Android NDK是什么,为什么我们要用NDK? Android NDK 是在SDK前面又加上了“原生”二字,即Native Development Ki...

糊涂熊
2014/12/16
16
0
如何定位Android NDK开发中遇到的错误

正式开始这个话题之前,先简单介绍一下什么是NDK和JNI,部分内容来自网络 Android NDK是什么,为什么我们要用NDK? Android NDK 是在SDK前面又加上了“原生”二字,即Native Development Ki...

糊涂熊
2014/12/16
15K
2
android游戏开发打印C++dmp

本人使用cocos2d-x来开发Android,在Android通过NDK来调用C++代码,但是每次游戏crash后,都只能打印出Java的堆栈,请教下如何在游戏crash的时候打印出C++堆栈...

captals
2012/12/04
568
0
【我的Android进阶之旅】Linux环境下如何安装NDK?

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 https://blog.csdn.net/qq446282412/article/details/91415049 文章目录 一、需求描述 随着项...

欧阳鹏
06/11
0
0
Android NDK开发的一点尝试

写在前面 笔者是一个“原始”的C++开发者,对Java编程虽说不上抵触但也没有C++那么顺手。而且,作为一个游戏引擎,不管是在什么地方,效率总是第一位的,尤其是在移动平台这样资源吃紧的环境...

闪电的蓝熊猫
2018/04/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

java通过ServerSocket与Socket实现通信

首先说一下ServerSocket与Socket. 1.ServerSocket ServerSocket是用来监听客户端Socket连接的类,如果没有连接会一直处于等待状态. ServetSocket有三个构造方法: (1) ServerSocket(int port);...

Blueeeeeee
今天
6
0
用 Sphinx 搭建博客时,如何自定义插件?

之前有不少同学看过我的个人博客(http://python-online.cn),也根据我写的教程完成了自己个人站点的搭建。 点此:使用 Python 30分钟 教你快速搭建一个博客 为防有的同学不清楚 Sphinx ,这...

王炳明
昨天
5
0
黑客之道-40本书籍助你快速入门黑客技术免费下载

场景 黑客是一个中文词语,皆源自英文hacker,随着灰鸽子的出现,灰鸽子成为了很多假借黑客名义控制他人电脑的黑客技术,于是出现了“骇客”与"黑客"分家。2012年电影频道节目中心出品的电影...

badaoliumang
昨天
16
0
很遗憾,没有一篇文章能讲清楚线程的生命周期!

(手机横屏看源码更方便) 注:java源码分析部分如无特殊说明均基于 java8 版本。 简介 大家都知道线程是有生命周期,但是彤哥可以认真负责地告诉你网上几乎没有一篇文章讲得是完全正确的。 ...

彤哥读源码
昨天
19
0
jquery--DOM操作基础

本文转载于:专业的前端网站➭jquery--DOM操作基础 元素的访问 元素属性操作 获取:attr(name);$("#my").attr("src"); 设置:attr(name,value);$("#myImg").attr("src","images/1.jpg"); ......

前端老手
昨天
7
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部