Android NDK开发Crash错误定位（转）

最新推荐文章于 2022-11-15 21:28:19 发布

xianglongjifei

最新推荐文章于 2022-11-15 21:28:19 发布

阅读量548

点赞数

分类专栏： jni java c++

原文链接：http://blog.csdn.net/xyang81/article/details/42319789，http://www.cnblogs.com/lancidie/archive/2013/04/13/3019349.html

版权

java 同时被 3 个专栏收录

2 篇文章 0 订阅

订阅专栏

jni

1 篇文章 0 订阅

订阅专栏

c++

1 篇文章 0 订阅

订阅专栏

出处：http://blog.csdn.net/xyang81/article/details/42319789

一、定位jni错误

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

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项目来演示一下如何精确的定位错误

#include <string.h>
#include <jni.h>
// hell-jni.c
#ifdef __cplusplus
extern "C" {
#endif
   void willCrash()
   {
       int i = 10;
       int y = i / 0;
   }

   JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
   {
       willCrash();
       return JNI_VERSION_1_4;
   }

   jstring
   Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
                                                   jobject thiz )
   {
   // 此处省略实现逻辑。。。
   }

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

01-01 17:59:38.246: D/dalvikvm(20794): Late-enabling CheckJNI
01-01 17:59:38.246: I/ActivityManager(1185):
Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid=20794 uid=10351 gids={50351, 1028, 1015}
01-01 17:59:38.296: I/dalvikvm(20794): Enabling JNI app bug workarounds for target SDK version 3...
01-01 17:59:38.366: D/dalvikvm(20794): Trying to load lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=-6), thread 20794 (xample.hellojni)
01-01 17:59:38.476: I/DEBUG(253): pid: 20794, tid: 20794, name: xample.hellojni >>> com.example.hellojni <<<
01-01 17:59:38.476: I/DEBUG(253): signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000513a
01-01 17:59:38.586: I/DEBUG(253): r0 00000000 r1 0000513a r2 00000008 r3 00000000
01-01 17:59:38.586: I/DEBUG(253): r4 00000008 r5 0000000d r6 0000513a r7 0000010c
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:
01-01 17:59:38.596: I/DEBUG(253): #00 pc 0002210c /system/lib/libc.so (tgkill+12)
01-01 17:59:38.596: I/DEBUG(253): #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
01-01 17:59:38.596: I/DEBUG(253): #02 pc 00013379 /system/lib/libc.so (raise+10)
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)
01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
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)
01-01 17:59:38.596: I/DEBUG(253): #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
01-01 17:59:38.596: I/DEBUG(253): #07 pc 0006a62d /system/lib/libdvm.so
01-01 17:59:38.596: I/DEBUG(253): // 省略部份日志。。。。。。
01-01 17:59:38.596: I/DEBUG(253): stack:
01-01 17:59:38.596: I/DEBUG(253): bedbf0b0 71b17034 /system/lib/libsechook.so
01-01 17:59:38.596: I/DEBUG(253): bedbf0b4 7521ce28
01-01 17:59:38.596: I/DEBUG(253): bedbf0b8 71b17030 /system/lib/libsechook.so
01-01 17:59:38.596: I/DEBUG(253): bedbf0bc 4012c3cf /system/lib/libc.so (dlfree+50)
01-01 17:59:38.596: I/DEBUG(253): bedbf0c0 40165000 /system/lib/libc.so
01-01 17:59:38.596: I/DEBUG(253): // 省略部份日志。。。。。。
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文件和定义的两个函数，在这里引发了异常，导致程序崩溃。

01-01 17:59:38.596: I/DEBUG(253): #04 pc 00000cf4 /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
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为例，执行如下命令：

/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的函数表信息：

/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架构为例，执行如下命令：

adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a
当程序发生crash时，会输出如下信息：
pid: 22654, tid: 22654, name: xample.hellojni >>> com.example.hellojni <<<
signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000587e
Stack frame #00 pc 0002210c /system/lib/libc.so (tgkill+12)
Stack frame #01 pc 00013165 /system/lib/libc.so (pthread_kill+48)
Stack frame #02 pc 00013379 /system/lib/libc.so (raise+10)
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
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
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
Stack frame #06 pc 00052eb1 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
Stack frame #07 pc 0006a62d /system/lib/libdvm.so
第7行和第8行分别打印出了在源文件中出错的位置，和addr2line得到的结果一样。
先获取日志再分析：
这种方式和上面的方法差不多，只是获取log的来源不一样。适用于应用或游戏给测试部们测试的时候，测试人员发现crash，用adb logcat保存日志文件，然后发给程序员通过ndk-stack命令分析。操作流程如下：

adb logcat > crash.log
ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log
得到的结果和上面的方式是一样的。

二、android崩溃捕获和收集

1、android开启崩溃捕获

首先是java代码的崩溃捕获，这个可以仿照最下面的完整代码写一个UncaughtExceptionHandler，然后在所有的Activity的onCreate函数最开始调用
Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler(this));

这样，当发生崩溃的时候，就会自动调用UncaughtExceptionHandler的public void uncaughtException(Thread thread, Throwable exception)函数，其中的exception包含堆栈信息，我们可以在这个函数里面打印我们需要的信息，并且上传错误日志

然后是重中之重，jni的c++代码如何进行崩溃捕获。

[cpp] view plain copy

void InitCrashReport()
{
CCLOG("InitCrashReport");
// Try to catch crashes...
struct sigaction handler;
memset(&handler, 0, sizeof(struct sigaction));
handler.sa_sigaction = android_sigaction;
handler.sa_flags = SA_RESETHAND;
#define CATCHSIG(X) sigaction(X, &handler, &old_sa[X])
CATCHSIG(SIGILL);
CATCHSIG(SIGABRT);
CATCHSIG(SIGBUS);
CATCHSIG(SIGFPE);
CATCHSIG(SIGSEGV);
CATCHSIG(SIGSTKFLT);
CATCHSIG(SIGPIPE);
}

通过singal的设置，当崩溃发生的时候就会调用android_sigaction函数。这同样是linux的信号机制。此处设置信号回调函数的代码跟iOS有点不同，这个只是同一个功能的两种不同写法，没有本质区别。有兴趣的可以google下两者的区别。

2、打印堆栈

java语法可以直接通过exception获取到堆栈信息，但是jni代码不支持backtrace，那么我们如何获取堆栈信息呢？这里有个我想尝试的新方法，就是使用google breakpad，貌似它现在完整的跨平台了（支持windows, mac, linux, iOS和android等），它自己实现了一套minidump，在android上面限制会小很多。但是这个库有些大，估计要加到我们的工程中不是一件非常容易的事，所以我们还是使用了简洁的“传统”方案。思路是，当发生崩溃的时候，在回调函数里面调用一个我们在Activity写好的静态函数。在这个函数里面通过执行命令获取logcat的输出信息（输出信息里面包含了jni的崩溃地址），然后上传这个崩溃信息。当我们获取到崩溃信息后，可以通过前面三种方法解析崩溃信息。

jni的崩溃回调函数如下：

[cpp] view plain copy

void android_sigaction(int signal, siginfo_t *info, void *reserved)
{
if (!g_env) {
return;
}
jclass classID = g_env->FindClass(CLASS_NAME);
if (!classID) {
return;
}
jmethodID methodID = g_env->GetStaticMethodID(classID, "onNativeCrashed", "()V");
if (!methodID) {
return;
}
g_env->CallStaticVoidMethod(classID, methodID);
old_sa[signal].sa_handler(signal);
}

可以看到，我们仅仅是通过jni调用了java的一个函数，然后所有的处理都是在java层面完成。

java对应的函数实现如下：

[java] view plain copy

public static void onNativeCrashed() {
// http://stackoverflow.com/questions/1083154/how-can-i-catch-sigsegv-segmentation-fault-and-get-a-stack-trace-under-jni-on-a
Log.e("handller", "handle");
new RuntimeException("crashed here (native trace should follow after the Java trace)").printStackTrace();
s_instance.startActivity(new Intent(s_instance, CrashHandler.class));
}

我们开启了一个新的activity，因为当jni发生崩溃的时候，原始的activity可能已经结束掉了。这个新的activity实现如下：

[java] view plain copy

public class CrashHandler extends Activity
{
public static final String TAG = "CrashHandler";
protected void onCreate(Bundle state)
{
super.onCreate(state);
setTitle(R.string.crash_title);
setContentView(R.layout.crashhandler);
TextView v = (TextView)findViewById(R.id.crashText);
v.setText(MessageFormat.format(getString(R.string.crashed), getString(R.string.app_name)));
final Button b = (Button)findViewById(R.id.report),
c = (Button)findViewById(R.id.close);
b.setOnClickListener(new View.OnClickListener(){
public void onClick(View v){
final ProgressDialog progress = new ProgressDialog(CrashHandler.this);
progress.setMessage(getString(R.string.getting_log));
progress.setIndeterminate(true);
progress.setCancelable(false);
progress.show();
final AsyncTask task = new LogTask(CrashHandler.this, progress).execute();
b.postDelayed(new Runnable(){
public void run(){
if (task.getStatus() == AsyncTask.Status.FINISHED)
return;
// It's probably one of these devices where some fool broke logcat.
progress.dismiss();
task.cancel(true);
new AlertDialog.Builder(CrashHandler.this)
.setMessage(MessageFormat.format(getString(R.string.get_log_failed), getString(R.string.author_email)))
.setCancelable(true)
.setIcon(android.R.drawable.ic_dialog_alert)
.show();
}}, 3000);
}});
c.setOnClickListener(new View.OnClickListener(){
public void onClick(View v){
finish();
}});
}
static String getVersion(Context c)
{
try {
return c.getPackageManager().getPackageInfo(c.getPackageName(),0).versionName;
} catch(Exception e) {
return c.getString(R.string.unknown_version);
}
}
}
class LogTask extends AsyncTask<Void, Void, Void>
{
Activity activity;
String logText;
Process process;
ProgressDialog progress;
LogTask(Activity a, ProgressDialog p) {
activity = a;
progress = p;
}
@Override
protected Void doInBackground(Void... v) {
try {
Log.e("crash", "doInBackground begin");
process = Runtime.getRuntime().exec(new String[]{"logcat","-d","-t","500","-v","threadtime"});
logText = UncaughtExceptionHandler.readFromLogcat(process.getInputStream());
Log.e("crash", "doInBackground end");
} catch (IOException e) {
e.printStackTrace();
Toast.makeText(activity, e.toString(), Toast.LENGTH_LONG).show();
}
return null;
}
@Override
protected void onCancelled() {
Log.e("crash", "onCancelled");
process.destroy();
}
@Override
protected void onPostExecute(Void v) {
Log.e("crash", "onPostExecute");
progress.setMessage(activity.getString(R.string.starting_email));
UncaughtExceptionHandler.sendLog(logText, activity);
progress.dismiss();
activity.finish();
Log.e("crash", "onPostExecute over");
}