[Replicant/Lineage] 1.9.1 causing instant crash and bootloops

  • Same problem and solution with CyanogenMod 12.1, F-Droid 1.0.1

    Seeing that everyone who mention their package manager above use F-Droid, I imagine the problem may be with the F-Droid build.
    I opened a ticket there with the hope it can help move the topic forward:

  • Here too. LineageOS 13.0 on a Nexus 10, installed via the Google Play store.

  • Same problem here with a custom KitKat ROM. Linked from https://stackoverflow.com/questions/47051166/app-cant-run-on-devices-below-android-7-1-after-migrating-to-android-studio-3, https://issuetracker.google.com/issues/64434571#comment19 tells us how this ROM flaw can be mitigated:

    If you need to build with (Android Studio & Gradle) 3.0 but are running into this bug you can disable aapt2 using -Pandroid.enableAapt2=false on the command line when doing your build.

    And https://issuetracker.google.com/issues/64434571#comment22 has the details:

    CyanogenMod has this function getPkgName (https://github.com/CyanogenMod/android_frameworks_base/blob/cm-13.0/libs/androidfw/AssetManager.cpp). It creates a ResXMLTree on the stack and points it at a buffer from an asset without making a copy. Then it closes the asset before the ResXMLTree is destroyed.

    For apps built by aapt, this is benign. However, aapt2 produces UTF-8 string pools, which cause the ResXMLTree’s ResStringPool(mStrings)'s mCache to become non-null in ResStringPool::stringAt (https://github.com/CyanogenMod/android_frameworks_base/blob/cm-13.0/libs/androidfw/ResourceTypes.cpp). Then ResStringPool::uninit dereferences mHeader (which is now dangling), and a crash ensues.

    This crash shows up in different ways. On one Cyanogen OS device, the launcher crashes when an app built with aapt2 has been installed, but only if the manifest is large (probably due to how deallocation happens for small vs large blobs). On another device, system_server crashes at boot if an aapt2-built app is installed.

    We’re attempting to work around this with a custom build of aapt2 that always produces a UTF-16 string pool for the manifest. Results so far are promising.

    While in https://issuetracker.google.com/issues/64434571#comment34 s/o by google explains who’s fault it is

    Just to be clear, this is a device that introduced a memory corruption bug, which when running an app built with aapt2, happens to be exposed. The device is running with undefined behavior regardless of which tool you use.

    We can fix this so as not to trigger the worst case scenario, but there is no guarantee that this won’t be broken later by subsequent changes, like legal ordering changes in the resource table.

    That being said, I will be writing a CTS test to ensure that OEMs who introduced this “feature” fix the bug.

  • @rfc2822 said in [Replicant/Lineage] 1.9.1 causing instant crash and bootloops:

    @cjeudico Did you already search for this CyanogenMod problem / did you find something? Or did you have at the logs and find something useful? Is it a libc crash, too?

    No, I did not search anywhere besides this forum. However, I do have a logcat log now.

    I removed DAVDroid and then installed DAVDroid 1.9.1 in F-Droid. The log below is a snippet from during the installation.
    It contains error messages for android::ResStringPool::uninit() which matches what @azrdev has written.

    11-03 22:21:02.714: I/ActivityManager(664): START u0 {act=android.intent.action.INSTALL_PACKAGE dat=file:///data/user/0/org.fdroid.fdroid/files/DAVdroid-1.9.1-ose.apk cmp=com.android.packageinstaller/.PackageInstallerActivity (has extras)} from uid 10055 on display 0
    11-03 22:21:02.920: W/System(4519): ClassLoader referenced unknown path: /system/priv-app/PackageInstaller/lib/arm
    11-03 22:21:03.564: I/ActivityManager(664): Displayed com.android.packageinstaller/.PackageInstallerActivity: +807ms (total +862ms)
    11-03 22:21:04.505: I/ActivityManager(664): START u0 {dat=file:///data/user/0/org.fdroid.fdroid/files/DAVdroid-1.9.1-ose.apk flg=0x2000000 cmp=com.android.packageinstaller/.InstallAppProgress (has extras)} from uid 10013 on display 0
    11-03 22:21:04.577: I/ActivityManager(664): Start proc 4557:com.android.defcontainer/u0a7 for service com.android.defcontainer/.DefaultContainerService
    11-03 22:21:04.672: I/ActivityManager(664): Displayed com.android.packageinstaller/.InstallAppProgress: +144ms
    11-03 22:21:04.752: I/Finsky(2472): [1] com.google.android.finsky.verifier.impl.PackageVerificationReceiver.onReceive(14): Verification requested, id = 0
    11-03 22:21:04.752: I/Finsky(2472): --------- beginning of crash
    11-03 22:21:06.927: A/libc(2472): invalid address or address of corrupt block 0x13 passed to dlfree
    11-03 22:21:06.939: A/libc(2472): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdeadbaad in tid 2891 (AsyncTask #5)
    11-03 22:21:06.940: I/DEBUG(223): property debug.db.uid not set; NOT waiting for gdb.
    11-03 22:21:06.940: I/DEBUG(223): HINT: adb shell setprop debug.db.uid 100000
    11-03 22:21:06.940: I/DEBUG(223): HINT: adb forward tcp:5039 tcp:5039
    11-03 22:21:06.996: A/DEBUG(223): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    11-03 22:21:06.996: A/DEBUG(223): Build fingerprint: 'google/occam/mako:5.1.1/LMY48M/2167285:user/release-keys'
    11-03 22:21:06.996: A/DEBUG(223): Revision: '0'
    11-03 22:21:06.996: A/DEBUG(223): ABI: 'arm'
    11-03 22:21:06.996: A/DEBUG(223): pid: 2472, tid: 2891, name: AsyncTask #5  >>> com.android.vending <<<
    11-03 22:21:06.996: A/DEBUG(223): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdeadbaad
    11-03 22:21:07.048: A/DEBUG(223): Abort message: 'invalid address or address of corrupt block 0x13 passed to dlfree'
    11-03 22:21:07.049: A/DEBUG(223):     r0 00000000  r1 00000000  r2 00000000  r3 00000002
    11-03 22:21:07.049: A/DEBUG(223):     r4 00000013  r5 deadbaad  r6 b6cceeb8  r7 9c744000
    11-03 22:21:07.049: A/DEBUG(223):     r8 0000001b  r9 9c887fbc  sl b6c2f843  fp b6c2f84c
    11-03 22:21:07.049: A/DEBUG(223):     ip b6cc95dc  sp 9c887ea8  lr b6c9a497  pc b6c9a496  cpsr 600f0030
    11-03 22:21:07.064: A/DEBUG(223): backtrace:
    11-03 22:21:07.064: A/DEBUG(223):     #00 pc 00030496  /system/lib/libc.so (dlfree+1285)
    11-03 22:21:07.065: A/DEBUG(223):     #01 pc 00015769  /system/lib/libandroidfw.so (android::ResStringPool::uninit()+38)
    11-03 22:21:07.069: A/DEBUG(223):     #02 pc 000164b9  /system/lib/libandroidfw.so (android::ResXMLTree::uninit()+14)
    11-03 22:21:07.069: A/DEBUG(223):     #03 pc 000164d7  /system/lib/libandroidfw.so (android::ResXMLTree::~ResXMLTree()+4)
    11-03 22:21:07.070: A/DEBUG(223):     #04 pc 00013223  /system/lib/libandroidfw.so (android::AssetManager::getPkgName(char const*)+258)
    11-03 22:21:07.070: A/DEBUG(223):     #05 pc 0001327f  /system/lib/libandroidfw.so (android::AssetManager::getBasePackageName(unsigned int)+62)
    11-03 22:21:07.071: A/DEBUG(223):     #06 pc 00087233  /system/lib/libandroid_runtime.so
    11-03 22:21:07.071: A/DEBUG(223):     #07 pc 71fa0c99  /data/dalvik-cache/arm/system@framework@boot.oat (offset 0x1f5f000)

  • developer

    I have sent you an APK which has been compiled with Android build tools version 27 per email. Please tell me whether it works for you.

  • @rfc2822 I can confirm your APK does not trigger the loop at boot, it fixes the issue. Thanks for your time!

  • developer

    We’ll make a new release. 1.9.2 will be compiled with build tools 27.

  • @rfc2822 yes, this works for me too. Thanks for the quick response.

  • When I select the 1.9.2 APK version and click on “install”, it doesn’t want to install. Android tells me “App not installed”. What I did wrong?

  • developer

    @cypouz Did you uninstall the old version first? Probably it was signed with another key (e.g. F-Droid key)

  • @rfc2822 thank you very much. It works fine on LineageOS 13.0 and Cyanogenmod 12.1. Cool 🙂

  • @rfc2822 Thanks for fixing this issue so quickly!

    Did you already publish version 1.9.2 to F-Droid? I can only see 1.9 at https://f-droid.org/packages/at.bitfire.davdroid/ .

  • developer

    @cjeudico We can’t publish to F-Droid. This is not how F-Droid works.

    But we have already published the 1.9.2-ose tag, which has already been found by the F-Droid update bot. So it will probably appear in F-Droid as soon as they update their apk list the next time. 🙂

  • @rfc2822 Oh, I see. Thanks for the explanation!

Similar topics