Android本机崩溃从/system/framework/arm/boot.oat启动 [英] Android native crash initiating from /system/framework/arm/boot.oat
问题描述
我最近更新了我在Google Play中的应用程序后，我开始收到大量的崩溃报告，所有的都是来自三星设备与Android 5.较低的Android版本工作正常，其他制造商与Android 5的设备也很好。 / p>
我没有任何可以重现问题的设备，所以我不能平分。我试图从崩溃报告和从我的上一个工作版本（这是不幸的很长时间）更改列表中，可能是错误的。
所有崩溃报告像这样（只是地址稍有不同的设备）：
建立指纹：'samsung / kltektt / kltektt：5.0 / LRX21T / G900KKTU1BOB1：user / release-keys'
修订：'15'
ABI：'arm'
pid：26265，tid：26265，name：mt.AnnelidsDemo& cz.gdmt.AnnelidsDemo<<<
信号11（SIGSEGV），代码1（SEGV_MAPERR），故障地址0x76f57e84
r0 00000800 r1 0000004b r2 b4aa9f9a r3 00000000
r4 1426e019 r5 76f57e80 r6 0000012c r7 76e6b040
r8 00000019 r9 76f57d54 sl 000007ff fp b4e1b330
ip b4aa9f70 sp bea94b50 lr b4bc72c1 pc b4c0d9b8 cpsr 00070030
backtrace：
＃00 pc 001099b8 /system/lib/libart.so（art :: TypeLookupTable :: Lookup（char const *）const + 59）
＃01 pc 000c32bd /system/lib/libart.so（art :: ClassLinker :: LookupClassFromImage（char const *，art :: gc :: space :: ImageSpace *）+ 64）
＃02 pc 000d27c1 /system/lib/libart.so（art :: ClassLinker :: DefineClass（char const *，art :: Handle< art :: mirror :: ClassLoader> :: DexFile const& art :: DexFile :: ClassDef const&）+ 320）
＃03 pc 000d2d89 /system/lib/libart.so（art :: ClassLinker :: FindClassInPathClassLoader（art :: ScopedObjectAccessAlreadyRunnable& art :: Thread *，char const *，art :: Handle< art :: mirror :: ClassLoader>）+ b）
＃04 pc 001fe20b /system/lib/libart.so（art :: VMClassLoader_findLoadedClass（_JNIEnv *，_jclass *，_jobject *，_jstring *）+ 254）
＃05 pc 0001b179 /system/framework/arm/boot.oat
我发现 art :: TypeLookupTable 是Samsung对ART的修改，没有可用的来源。
这个和最后的工作版本是用相同的Android SDK和NDK（目标是android-19）构建，没有在Java代码的变化，有很多的本机代码的变化，数据。我在构建本地代码时开始使用LTO。我开始使用 zipalign 的 -z （Zopfli）参数。
我的应用程序使用JNI，因此可能是第一个嫌疑人。但CheckJNI没有报告任何问题。相同的代码清楚地运行，在其他Android设备上，在IOS和Linux上没有任何崩溃。它不显示valgrind中的任何错误。所以我认为一些随机的内存损坏是不可能的。
我认为我的Java代码是确定的，但即使它有错误，它不应该引起segfault在java运行时。 ..
用户正在报告应用程序在启动过程中崩溃，甚至显示任何内容。
我问三星开发者论坛，到目前为止没有任何回应。
问题：
-
backtrace在boot.oat中启动，并在libart.so中继续。在boot.oat发生了什么？它是否有可能崩溃，甚至在达到我的任何代码之前？
-
任何想法可能是错误的，我可以尝试什么？
与其他开发人员一起在应用程序中遇到相同的崩溃，我们发现它是由工具的 -z 参数 zipalign （使用Zopfli重新压缩）
与Zopfli对齐并重新压缩时，完全相同的APK会崩溃，并且在未重新压缩的情况下对齐时不会崩溃。
我只能猜测三星对Android 5做了一些修改，并在读取APK的代码中引入了一些奇怪的错误。直到这是固定的或我有一些更好的解释，不使用 -z 在 zipalign 解决问题。 p>
After recent update of my application in Google Play, I started receiving lot of crash reports, all of them are from Samsung devices with Android 5. Lower android versions work fine and devices of other manufacturers with Android 5 work fine too.
I don't have any device where I could reproduce the issue, so I can't bisect. I am trying to deduce what could be wrong from the crash report and from list of changes since my last working version (which is unfortunately long).
All the crash reports look like this (just the addresses slightly vary between devices):
Build fingerprint: 'samsung/kltektt/kltektt:5.0/LRX21T/G900KKTU1BOB1:user/release-keys'
Revision: '15'
ABI: 'arm'
pid: 26265, tid: 26265, name: mt.AnnelidsDemo >>> cz.gdmt.AnnelidsDemo <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x76f57e84
r0 00000800 r1 0000004b r2 b4aa9f9a r3 00000000
r4 1426e019 r5 76f57e80 r6 0000012c r7 76e6b040
r8 00000019 r9 76f57d54 sl 000007ff fp b4e1b330
ip b4aa9f70 sp bea94b50 lr b4bc72c1 pc b4c0d9b8 cpsr 00070030
backtrace:
#00 pc 001099b8 /system/lib/libart.so (art::TypeLookupTable::Lookup(char const*) const+59)
#01 pc 000c32bd /system/lib/libart.so (art::ClassLinker::LookupClassFromImage(char const*, art::gc::space::ImageSpace*)+64)
#02 pc 000d27c1 /system/lib/libart.so (art::ClassLinker::DefineClass(char const*, art::Handle<art::mirror::ClassLoader>, art::DexFile const&, art::DexFile::ClassDef const&)+320)
#03 pc 000d2d89 /system/lib/libart.so (art::ClassLinker::FindClassInPathClassLoader(art::ScopedObjectAccessAlreadyRunnable&, art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+452)
#04 pc 001fe20b /system/lib/libart.so (art::VMClassLoader_findLoadedClass(_JNIEnv*, _jclass*, _jobject*, _jstring*)+254)
#05 pc 0001b179 /system/framework/arm/boot.oat
I found out that the art::TypeLookupTable is Samsung's modification of ART and there are no sources available.
Both this and last working versions are build with the same android SDK and NDK (target is android-19), there are no changes in Java code, there is lot of changes in native code and in data. I started using LTO when building native code. I started using -z (Zopfli) parameter of zipalign.
My application uses JNI, so that is probably the first suspect. However CheckJNI doesn't report any problems. The same code runs clearly without any crashes on other Android devices, on IOS and on Linux. It doesn't show any erros in valgrind. So I think some random memory corruption is unlikely.
I think my Java code is ok, but even if it had errors, it shouldn't cause segfault in java runtime...
Users are reporting that the application crashes during start, before even showing anything.
I asked on Samsung developers forum, so far without any response.
I have two questions:
The backtrace starts in boot.oat and continues in libart.so. What is happening in boot.oat? Is it possible that it crashes even before reaching any of my code? (That would indicate bug in Samsung's ART.)
Any idea what could be wrong, what could I try?
Together with one other developer, who was getting the same crash in his application, we discovered that it is triggered by the -z parameter of zipalign tool. (Recompress using Zopfli)
The exactly same APK crashes when aligned and recompressed with Zopfli and doesn't crash when aligned without recompressing.
I can only guess that Samsung made some modifications to the Android 5 and introduced some weird bug in the code that reads the APK. Until that is fixed or I have some better explanation, not using the -z in zipalign solves the problem.
这篇关于Android本机崩溃从/system/framework/arm/boot.oat启动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
