从/system/framework/arm/boot.oat 启动的 Android 本机崩溃 [英] Android native crash initiating from /system/framework/arm/boot.oat
问题描述
最近在 Google Play 中更新我的应用程序后，我开始收到很多崩溃报告，所有这些报告都是来自搭载 Android 5 的三星设备.较低的 android 版本可以正常工作，其他制造商的 Android 5 设备也可以正常工作.
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
我发现art::TypeLookupTable是三星对ART的修改，没有可用的资源.
I found out that the art::TypeLookupTable is Samsung's modification of ART and there are no sources available.
这个和上一个工作版本都是使用相同的 android SDK 和 NDK 构建的(目标是 android-19)，Java 代码没有变化，本机代码和数据有很多变化.我在构建本机代码时开始使用 LTO.我开始使用 zipalign 的 -z (Zopfli) 参数.
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.
我的应用程序使用 JNI，所以这可能是第一个嫌疑人.但是 CheckJNI 没有报告任何问题.相同的代码在其他 Android 设备、IOS 和 Linux 上运行清晰，没有任何崩溃.它在 valgrind 中没有显示任何错误.所以我认为一些随机内存损坏是不可能的.
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.
我认为我的 Java 代码还可以，但即使它有错误，它也不应该导致 java 运行时出现段错误...
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.
我有两个问题:
回溯从 boot.oat 开始并在 libart.so 中继续.boot.oat 中发生了什么?它是否有可能在到达我的任何代码之前就崩溃了?(这表明三星的 ART 存在错误.)
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?
推荐答案
与另一位在他的应用程序中遇到同样崩溃的开发人员一起，我们发现它是由 -z 触发的zipalign 工具的参数.(使用 Zopfli 重新压缩)
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)
完全相同的 APK 在使用 Zopfli 对齐和重新压缩时会崩溃，而在未重新压缩的情况下对齐时不会崩溃.
The exactly same APK crashes when aligned and recompressed with Zopfli and doesn't crash when aligned without recompressing.
我只能猜测三星对 Android 5 进行了一些修改，并在读取 APK 的代码中引入了一些奇怪的错误.在解决此问题或我有更好的解释之前，不使用 zipalign 中的 -z 可以解决问题.
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.
这篇关于从/system/framework/arm/boot.oat 启动的 Android 本机崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
