[Replicant/Lineage] 1.9.1 causing instant crash and bootloops

  • Currently running Replicant 6.0 0002 on an i9300.

    Upgraded from DAVdroid 1.9 -> 1.9.1 via F-Droid and it caused my phone to immediately crash, and force it to bootloop indefinitely.
    I was able to get into the phone via adb shell and move the /data/app/bitfire directory and get my phone booted.

    A clean install after this from F-Droid also caused the same issue.

  • developer

    We had a report that this error is related to firmware (libc crash; allegedly, the problem is related to the gradle version used when building). I don’t think it’s related to DAVdroid; other apps (OpenVPN) have been reported to show the same behavior.

    If you think this problem is caused by DAVdroid, please let us know more details why.

  • Same problem here on Alcatel Idol 3 with LineageOS 13.0. Crash and bootloop with DAVdroid 1.9.1. No problem with DAVdroid 1.9.

  • developer

    @cypouz Have you already investigated in LineageOS forums? Please tell us about the results.

  • Hi there,

    I am having exactly the same issue as OP.
    I upgraded to 1.9.1 today via F-Droid and my phone froze and went into a bootloop. I think before that I received a warning that Google Play Store or Services crashed.

    My phone is a Nexus 4 running Cyanogenmod 13 (Android 6).
    After removing DAVDroid 1.9.1 in Android safe mode I installed version 1.9 via F-Droid without problems.

    I am not using OpenVPN.

    If that’s of relevance: I installed Google Play Store from OpenGApps several months ago and have not had any problems so far.

    Thanks for looking into the issue!

  • developer

    @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?

  • Having the same issue on Cyanogenmod 13. Updated to version 1.9.1 from fdroid, and the instant it finished the phone crashed and entered a bootloop. I had to delete the davdroid folder from /data/app to get the phone to boot again. Seems like the issue is definitely with this version and people running CM/Lineage

  • Not sure if my me too helps much…I’ve had the same issue on Cyanogenmod 13. I had “Google Play Store” and “Data Usage” apps crash, then stuck in bootloop. Deleted apk as others have mentioned resolves the problem.

  • Me2.
    Cyanogenmod 13
    Back to 1.9 solves the problem…

  • 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 🙂

Similar topics