如何在Android上查找原生崩溃的原因

时间:2015-08-27 19:54:01

标签: android debugging

我的应用程序已经部署并且在几乎所有使用它的设备上都能正常工作,但是,在Android 5.1.1上,特别是LG G3,我收到了“本机崩溃”的崩溃日志。

def on_data(self, data): print json.loads(data)['text'].encode('utf-8') return True

Native crash at /system/lib64/libc.so

到目前为止,我所能完成的只是跟踪错误代码,直到从源代码中的*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Verizon/zerofltevzw/zerofltevzw:5.1.1/LMY47X/G920VVRU3BOG5:user/release-keys' Revision: '10' ABI: 'arm64' pid: 31341, tid: 31341, name: <companyName>.mobile >>> com.<companyName>.mobile <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- Abort message: 'sart/runtime/class_linker.cc:3135] Check failed: dex_cache.Get() != nullptr Failed to allocate dex cache for /data/app/com.google.android.gms-1/base.apk:classes2.dex' x0 0000000000000000 x1 0000000000007a6d x2 0000000000000006 x3 0000007f96649e30 x4 0000007f96649e30 x5 0000000000000005 x6 0000000000000001 x7 0000000000000020 x8 0000000000000083 x9 000000000000008a x10 0000007f963d6000 x11 0000000000000001 x12 0000000000000001 x13 0000007f963d6000 x14 f0ca73d6a9a36950 x15 000000000000000c x16 0000007f963d6610 x17 0000007f96376894 x18 0000000000000000 x19 0000007f96649e30 x20 0000007f9664a0e8 x21 0000007f963dc000 x22 0000000000000001 x23 0000000000000006 x24 0000007ff97b6020 x25 0000007f928a6000 x26 0000007ff97b6018 x27 0000007f927fd520 x28 0000007f928a6000 x29 0000007ff97b5ea0 x30 0000007f96338264 sp 0000007ff97b5ea0 pc 0000007f9637689c pstate 0000000060000000 backtrace: #00 pc 000000000005e89c /system/lib64/libc.so (tgkill+8) #01 pc 0000000000020260 /system/lib64/libc.so (pthread_kill+160) #02 pc 0000000000021794 /system/lib64/libc.so (raise+28) #03 pc 000000000001b17c /system/lib64/libc.so (abort+60) #04 pc 0000000000310144 /system/lib64/libart.so (art::Runtime::Abort()+300) #05 pc 00000000000d52b8 /system/lib64/libart.so (art::LogMessage::~LogMessage()+2684) #06 pc 00000000001161f4 /system/lib64/libart.so (art::ClassLinker::RegisterDexFile(art::DexFile const&)+728) #07 pc 000000000011d744 /system/lib64/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, unsigned long, art::Handle<art::mirror::ClassLoader>)+708) #08 pc 000000000011dcdc /system/lib64/libart.so (_ZN3art11ClassLinker9FindClassEPNS_6ThreadEPKcNS_6HandleINS_6mirror11ClassLoaderEEE.part.431+884) #09 pc 0000000000122010 /system/lib64/libart.so (art::ClassLinker::ResolveType(art::DexFile const&, unsigned short, art::Handle<art::mirror::DexCache>, art::Handle<art::mirror::ClassLoader>)+244) #10 pc 0000000000123588 /system/lib64/libart.so (art::ClassLinker::ResolveMethod(art::DexFile const&, unsigned int, art::Handle<art::mirror::DexCache>, art::Handle<art::mirror::ClassLoader>, art::Handle<art::mirror::ArtMethod>, art::InvokeType)+176) #11 pc 00000000003b03b8 /system/lib64/libart.so (art::ClassLinker::ResolveMethod(art::Thread*, unsigned int, art::mirror::ArtMethod**, art::InvokeType)+208) #12 pc 00000000003b5554 /system/lib64/libart.so (artQuickResolutionTrampoline+3044) #13 pc 00000000000cedd8 /system/lib64/libart.so (art_quick_resolution_trampoline+88) #14 pc 0000000002a4bb00 /data/dalvik-cache/arm64/data@app@com.google.android.gms-1@base.apk@classes.dex 方法抛出。不幸的是,这没有用,因为我不知道我能做些什么来解决这个问题。

我在谷歌上搜了一下,看看是否有任何记录过程来调试此类错误,但我找不到任何有意义的内容。

我该怎么做才能找到这个问题的根源?

编辑:因为这不是一个一致的问题,所以很难尝试解决,但是从我最近学到的有关Android编译过程的内容来看,这似乎是在编译期间传播的问题。我认为dex可能无意中在dex缓存中写了一个坏符号。当链接器尝试访问该方法的令牌时,它会跳出错误。

我仍然不确定如何解决这个问题,但我越来越接近理解,以解决它。

0 个答案:

没有答案