search

rovo89 / Xposed

The native part of the Xposed framework (mainly the modified app_process binary).
Other
7.4k stars 1.47k forks source link

App crash after some time #275

Closed 8monochrome closed 6 years ago

8monochrome commented 6 years ago

On oneplus 5 encrypted, magisk 14.3 and xposed 88.1, resurrection remix v5.8.5

App works fine, but after some time start crashing randomly. Clearing dalvik or reinstall app resolve temporarily but issue comes back

8monochrome commented 6 years ago 
Process: com.myfitnesspal.android Flags: 0x38c83e44
Package: com.myfitnesspal.android v10437 (6.25.1)
Foreground: Yes
Build: OnePlus/OnePlus5/OnePlus5:7.1.1/NMF26X/08141919:user/release-keys
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
LineageOS Version: 'unknown'
Build fingerprint: 'OnePlus/OnePlus5/OnePlus5:7.1.1/NMF26X/08141919:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 24378,
tid: 24450,
name: ConfigServiceIm
>>> com.myfitnesspal.android <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x271c x0 0000000000002710 x1 000000001328ec10 x2 0000000000000000 x3 0000000000000000 x4 0000000000000000 x5 0000000000000000 x6 0000000072da4868 x7 7f7f7f7f7f7f7f7f x8 0000007f747fdcf0 x9 000000000000000c x10 0000007f747fdd40 x11 0000000000000007 x12 0000000070710df8 x13 0000000000000001 x14 000000000000001f x15 000000000000000d x16 0000007f747fcfd0 x17 0000000000265233 x18 00000000703fc658 x19 0000000072ec7655 x20 0000000000002710 x21 000000001328ec10 x22 811e46689db21fb4 x23 0000000071595a0e x24 811e46689db21fb4 x25 811e46689db21fb4 x26 0000000000000000 x27 0000007f747fd270 x28 0000000000000001 x29 0000007f747fccc0 x30 0000007f98e1e74c sp 0000007f747fcc40 pc 0000007f98ab11f8 pstate 0000000080000000
backtrace: 
#00 pc 00000000000e11f8 /system/lib64/libart.so (_ZN3art9ArtMethod23GetOatQuickMethodHeaderEm+52)
#01 pc 000000000044e748 /system/lib64/libart.so (_ZN3art12StackVisitor9WalkStackEb+204)
#02 pc 0000000000453dc0 /system/lib64/libart.so (_ZNK3art6Thread24CreateInternalStackTraceILb0EEEP8_jobjectRKNS_33ScopedObjectAccessAlreadyRunnableE+108)
#03 pc 000000000039b0dc /system/lib64/libart.so (_ZN3artL32Throwable_nativeFillInStackTraceEP7_JNIEnvP7_jclass+56)
#04 pc 00000000739a947c /data/dalvik-cache/arm64/system@framework@boot.oat (offset 0x2a51000)
ghost commented 6 years ago

Same for me, in every morning to use apps i have to reinstall them On Moto G 2014 (titan) encrypted Lineage14.1 using add-on su16.0 Xposed 88.1 ,xposed installer is being force closed Here is log (truncated) https://hastebin.com/omeporewux.sql

wanam commented 6 years ago

@8monochrome @rovo89 FYI This Rom (Resurrection Remix) includes this commit: https://github.com/ResurrectionRemix/art/commit/8b76e427c34ef3f77e05caa88fa5d9519968ef68 and https://github.com/krexus/external_skia/commit/ad0e212cc0ecc66737c3982f6d8dd3eb98dc24c0

This commit disables FDO (Feedback-Directed Optimizations), i'm not sure if this could be related to the Rom, but i have tried OOS and 2 AOSP based Roms (other than RR) on my OP5 with no such issues.

Installed MyFitnessPal app few hours ago, i didn't manage to reproduce any crash.

@kumandr-raj Can you reproduce the crashes with xposed modules disabled?

Droidphilev commented 6 years ago

@wanam: i guess i won't be of big help but i had the same bug on a Motorola G4 Plus with stock rom.

wanam commented 6 years ago

@Droidphilev Maybe you could, disable your modules, and try to get a logcat.

Droidphilev commented 6 years ago

@wanam: i have this phone again the middle of next week :(

I do can tell that more and more people report that the problem is gone when Xprivacy module is disabled (which i couldn't try myself)

8monochrome commented 6 years ago

Updates:

@wanam My fitness pal is one of the apps, other apps include qoo10, pi music player and so on. You are spot on though, I do have xprivacy installed.

Temp work around (no issues yet)

  1. Removing profile code via terminal - app works immediately cmd package compile --reset my-package
  2. Suspect it was due to JIT, so I disabled it. So far all seems good. Will update with other findings if any.
akorn commented 6 years ago

FWIW, for me, cmd package compile --reset fixes the problem for individual applications, but setprop dalvik.vm.usejit false doesn't seem to help; they still break after a while and need a compile --reset.

I'm on a OnePlus A5000, running the xXx_NoLimits_4.1_OP5_Oxygen_4.5.13 ROM, with XPosed 88.2

Droidphilev commented 6 years ago

Same here. i added "dalvik.vm.usejit=false" to build.prop and all seemd well but after a while the problem was back :(

Droidphilev commented 6 years ago

about 'cmd package compile --reset' : is there a command to do this for all apps in 1 time? Or kan it only done app per app?

akorn commented 6 years ago

cmd package compile --reset -a should do it for all packages. See https://source.android.com/devices/tech/dalvik/jit-compiler.

akorn commented 6 years ago

I now also set dalvik.vm.usejitprofiles to false because "this may be used even if dalvik.vm.usejit is false"; I'll report back once I know whether this helps.

Droidphilev commented 6 years ago

yes, if you wouldn't mind reporting that would be very nice. I will only try the "cmd package compile --reset -a" only and will report here also

Droidphilev commented 6 years ago

Hi, i did this: Last night i added "dalvik.vm.usejit=false" and "dalvik.vm.usejitprofiles=false" to build.prop and rebooted. Put the phone to charge and this morning Google Docs strated crashing. So these commands don't seem to fix it. Still i tried "cmd package compile --reset -a" in terminal and this indeed fixes it (which is at least far more easy than rebooting to twrp and wip caches etc)

akorn commented 6 years ago

I confirm; same here. The two dalvik settings seem to have no effect on the crashing.

8monochrome commented 6 years ago

try to add dalvik.vm.usefitprofiles=false as well to build.prop. After which on boot, run adb shell cmd package compile -m everything -f -a

Droidphilev commented 6 years ago

8monochrome, ok i will. Leave both "dalvik.vm.usejit=false" and "dalvik.vm.usejitprofiles=false" in build.prop also? Or remove them and only add "dalvik.vm.usefitprofiles=false"?

markanthony1 commented 6 years ago

Running command in terminal does not fix the issue for me, even in adb. In adb mode i get error "security exception: only system can clear all profiles data". I have added all the props mentioned in the discussion but it did not help.

esgie commented 6 years ago

@markanthony1 You may try: for pkg in $( cmd package list packages | cut -f 2 -d : ); do cmd package compile --reset $pkg; done This loop will apply the command to all packages one by one, which hopefully won't be forbidden. You can limit it only to system apps or third party apps by adding switches -s or -3 after "cmd package list packages" command (i.e. ...cmd package list packages -s | cut ....)

wico commented 6 years ago

Btw, worth to read: https://developer.android.com/about/versions/nougat/android-7.0.html#jit_aot + https://www.infoq.com/news/2016/03/android-n-aot-jit (for those like me wondering whats going on ...). I unfortunately can't find an option to disable that globally on runtime (e.g. via build.prop).

Those 2: dalvik.vm.usejit=false dalvik.vm.usejitprofiles=false

... won't help as they (afaik) only disable (old?) JIT but not the "hybrid approach".

wico commented 6 years ago

Appendix:

What about that:

"pm.dexopt.bg-dexopt=speed-profile This is the compilation filter used when the device is idle, charging and fully charged. Try the speed-profile compiler filter to take advantage of profile-guided compilation and save on storage."

Source: https://source.android.com/devices/tech/dalvik/configure#runtime_configuration

I will try that with: pm.dexopt.bg-dexopt=verify

Maybe it does the trick as "verify" seems to just do some verification but no recompilation. Maybe one should also set pm.dexopt.boot=speed and/or pm.dexopt.install=speed to do the optimization in a more controlled behaviour (after a fresh boot / app install instead when device is idle).

wico commented 6 years ago

I spend more then 4h today and tried all permutations of:

dalvik.vm.usejit=false|true dalvik.vm.usejitprofiles=false|true pm.dexopt.install=verify|quicken|speed-profile|speed pm.dexopt.bg-dexopt=verify|quicken|speed-profile|speed pm.dexopt.boot=verify|quicken|speed-profile|speed pm.dexopt.first-boot=verify|quicken|speed-profile|speed

What I can say: As soon as anything set like: pm.dexopt.bg-dexopt=verify|quicken

... android does not boot anymore.

If I set pm.dexopt.bg-dexopt=speed-profile (the default), it boots ...

Sorry, for no good news ... I really tried. :(

rovo89 commented 6 years ago

I tried to reproduce this, but somehow couldn't. It doesn't crash for me. Do you get this even with no modules enabled? After resetting the JIT profile (which seems to get it working again), can you retrigger the bug with adb shell cmd package compile -m speed -f <package>?

wico commented 6 years ago

FYI - in my case, the problem happens with:

LineageOS 14.1-20171109 XPosed 88.2 AND - only if XPrivacy is enabled and if I wait ~1 day (e.g. trigger the speed-profile optimiziation over night).

If I disable XPrivacy, everything works smooth. Maybe I should have mentioned it, sorry for that. So, if no modules enabled, all works fine. Even if something else is enabled (like AFWall+), no problems. Only XPrivacy + XPosed seems to trigger it (at least for me).

With the XPosed from PurifyOS and the same LineageOS + same XPrivacy, it worked well btw. I then made a complete wipe, installed everything fresh + added XPosed 88.2 -> bingo.

Maybe you have seen the last discussions about XPrivacy+XPosed: https://forum.xda-developers.com/xposed/modules/xprivacy-ultimate-android-privacy-app-t2320783/post74542160#post74542160 ... thats why I ended up here. ;)

I will try to manually speed-compile and report back asap.

wico commented 6 years ago

Sorry for the many updates - but its really hard to reproduce. I was able to trigger that problem once:

1) cmd package compile -m speed -f com.xing.android 2) Xing still works 3) cmd package compile -m speed -f biz.bokhorst.xprivacy 4) Xing crashes

Now I tried to reproduce the exact same thing with no success. Damn ... :(

To have something to check further, I did a cmd package compile -m speed -a. Lets see what tomorrow brings...

wico commented 6 years ago

Here is a logcat output of a freshly crashing app:

11-26 18:01:32.476  1480  2043 I ActivityManager: Start proc 27906:no.nrk.yr/u0a191 for activity no.nrk.yr/.StartActivity
11-26 18:01:32.516 27906 27906 I art     : Starting a blocking GC AddRemoveAppImageSpace
11-26 18:01:32.519 27906 27906 W System  : ClassLoader referenced unknown path: /data/app/no.nrk.yr-2/lib/arm64
11-26 18:01:32.537 27906 27906 I FixedAndroidHandler: logging to file is not enabled
11-26 18:01:32.593 27906 27906 W XPrivacy: Hooking package=no.nrk.yr
11-26 18:01:32.641 27906 27906 W art     : Before Android 4.1, method double java.util.concurrent.ThreadLocalRandom.internalNextDouble(double, double) would have incorrectly overridden the package-private method in java.util.Random
11-26 18:01:32.641 27906 27906 W art     : Before Android 4.1, method int java.util.concurrent.ThreadLocalRandom.internalNextInt(int, int) would have incorrectly overridden the package-private method in java.util.Random
11-26 18:01:32.641 27906 27906 W art     : Before Android 4.1, method long java.util.concurrent.ThreadLocalRandom.internalNextLong(long, long) would have incorrectly overridden the package-private method in java.util.Random
11-26 18:01:32.649 27906 27906 D NetworkSecurityConfig: No Network Security Config specified, using platform default
11-26 18:01:32.682 27906 27906 I CrashlyticsCore: Initializing Crashlytics 2.3.17.dev
11-26 18:01:32.712 27906 27938 D ApplicationLoaders: ignored Vulkan layer search path /data/app/com.google.android.gms-2/lib/arm64:/system/fake-libs64:/data/app/com.google.android.gms-2/base.apk!/lib/arm64-v8a for namespace 0x7f811fa0f0
11-26 18:01:32.714 27906 27938 W XPrivacy: Hooking package=com.google.android.gms
11-26 18:01:32.742  1480  4556 I ActivityManager: START u0 {cmp=no.nrk.yr/.weatherdetail.WeatherDetailActivity} from uid 10191 on display 0
11-26 18:01:32.788 27906 27906 F art     : art/runtime/class_linker.cc:2728] Check failed: found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal android.icu.math.BigDecimal.toBigDecimal()
11-26 18:01:32.802 27906 27906 F art     : art/runtime/class_linker.cc:2728] Check failed: found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal android.icu.math.BigDecimal.toBigDecimal()
11-26 18:01:32.802 27906 27906 F art     : art/runtime/runtime.cc:423] Runtime aborting --- recursively, so no thread-specific detail!
11-26 18:01:32.802 27906 27906 F art     : art/runtime/runtime.cc:423] 
11-26 18:01:32.803 27906 27906 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 27906 (no.nrk.yr)
11-26 18:01:32.803   422   422 W         : debuggerd: handling request: pid=27906 uid=10191 gid=10191 tid=27906
11-26 18:01:32.869 27946 27946 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-26 18:01:32.869 27946 27946 F DEBUG   : LineageOS Version: '14.1-20171109-NIGHTLY-mido'
11-26 18:01:32.869 27946 27946 F DEBUG   : Build fingerprint: 'xiaomi/mido/mido:7.0/NRD90M/V8.5.4.0.NCFMIED:user/release-keys'
11-26 18:01:32.869 27946 27946 F DEBUG   : Revision: '0'
11-26 18:01:32.869 27946 27946 F DEBUG   : ABI: 'arm64'
11-26 18:01:32.870 27946 27946 F DEBUG   : pid: 27906, tid: 27906, name: no.nrk.yr  >>> no.nrk.yr <<<
11-26 18:01:32.870 27946 27946 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
11-26 18:01:32.872 27946 27946 F DEBUG   : Abort message: 'art/runtime/class_linker.cc:2728] Check failed: found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal android.icu.math.BigDecimal.toBigDecimal()'
11-26 18:01:32.872 27946 27946 F DEBUG   :     x0   0000000000000000  x1   0000000000006d02  x2   0000000000000006  x3   0000000000000008
11-26 18:01:32.872 27946 27946 F DEBUG   :     x4   00000000000001e9  x5   0000800000000000  x6   0000007f8147d000  x7   0000000000000000
11-26 18:01:32.872 27946 27946 F DEBUG   :     x8   0000000000000083  x9   ffffffffffffffdf  x10  0000000000000000  x11  0000000000000001
11-26 18:01:32.872 27946 27946 F DEBUG   :     x12  ffffffffffffffff  x13  0000000000000000  x14  0000000000000000  x15  002fd72e05a3fd37
11-26 18:01:32.872 27946 27946 F DEBUG   :     x16  0000007f7e014ec8  x17  0000007f7dfbe828  x18  0000000000000000  x19  0000007f81534b40
11-26 18:01:32.872 27946 27946 F DEBUG   :     x20  0000000000000006  x21  0000007f81534a98  x22  0000000000000002  x23  0000000000000016
11-26 18:01:32.872 27946 27946 F DEBUG   :     x24  0000007f7d6d1680  x25  0000000000000000  x26  000000006f58d020  x27  0000007fd4f605c1
11-26 18:01:32.872 27946 27946 F DEBUG   :     x28  0000000000000001  x29  0000007fd4f604c0  x30  0000007f7dfbbcd0
11-26 18:01:32.872 27946 27946 F DEBUG   :     sp   0000007fd4f604a0  pc   0000007f7dfbe830  pstate 0000000060000000
11-26 18:01:32.884 27946 27946 F DEBUG   : 
11-26 18:01:32.884 27946 27946 F DEBUG   : backtrace:
11-26 18:01:32.884 27946 27946 F DEBUG   :     #00 pc 000000000006c830  /system/lib64/libc.so (tgkill+8)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #01 pc 0000000000069ccc  /system/lib64/libc.so (pthread_kill+64)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #02 pc 0000000000023ea0  /system/lib64/libc.so (raise+24)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #03 pc 000000000001c924  /system/lib64/libc.so (abort+52)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #04 pc 0000000000438548  /system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+456)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #05 pc 00000000000e768c  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+1604)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #06 pc 000000000012be9c  /system/lib64/libart.so (_ZN3art11ClassLinker16FindOatMethodForEPNS_9ArtMethodEPb+500)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #07 pc 00000000000e12c4  /system/lib64/libart.so (_ZN3art9ArtMethod23GetOatQuickMethodHeaderEm+256)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #08 pc 000000000044eb5c  /system/lib64/libart.so (_ZN3art12StackVisitor9WalkStackEb+204)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #09 pc 000000000044d6d8  /system/lib64/libart.so (_ZNK3art12StackVisitor7GetVRegEPNS_9ArtMethodEtNS_8VRegKindEPj+140)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #10 pc 000000000038224c  /system/lib64/libart.so (_ZN3art7Monitor10VisitLocksEPNS_12StackVisitorEPFvPNS_6mirror6ObjectEPvES6_b+1712)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #11 pc 0000000000467150  /system/lib64/libart.so (_ZN3art16StackDumpVisitor10VisitFrameEv+692)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #12 pc 000000000044ed2c  /system/lib64/libart.so (_ZN3art12StackVisitor9WalkStackEb+668)
11-26 18:01:32.884 27946 27946 F DEBUG   :     #13 pc 000000000045d308  /system/lib64/libart.so (_ZNK3art6Thread13DumpJavaStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+300)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #14 pc 0000000000459f50  /system/lib64/libart.so (_ZNK3art6Thread9DumpStackERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEbP12BacktraceMap+484)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #15 pc 0000000000447fb4  /system/lib64/libart.so (_ZNK3art10AbortState10DumpThreadERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEEPNS_6ThreadE+56)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #16 pc 0000000000447dd4  /system/lib64/libart.so (_ZNK3art10AbortState4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+576)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #17 pc 0000000000438410  /system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+144)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #18 pc 00000000000e768c  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+1604)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #19 pc 000000000012be9c  /system/lib64/libart.so (_ZN3art11ClassLinker16FindOatMethodForEPNS_9ArtMethodEPb+500)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #20 pc 00000000000e12c4  /system/lib64/libart.so (_ZN3art9ArtMethod23GetOatQuickMethodHeaderEm+256)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #21 pc 000000000044eb5c  /system/lib64/libart.so (_ZN3art12StackVisitor9WalkStackEb+204)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #22 pc 00000000004541d4  /system/lib64/libart.so (_ZNK3art6Thread24CreateInternalStackTraceILb0EEEP8_jobjectRKNS_33ScopedObjectAccessAlreadyRunnableE+108)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #23 pc 000000000038e404  /system/lib64/libart.so (_ZN3artL27VMStack_getThreadStackTraceEP7_JNIEnvP7_jclassP8_jobject+56)
11-26 18:01:32.885 27946 27946 F DEBUG   :     #24 pc 0000000071316078  /data/dalvik-cache/arm64/system@framework@boot-core-libart.oat (offset 0x4a1000)
11-26 18:01:33.104  1480 27951 W ActivityManager:   Force finishing activity no.nrk.yr/.weatherdetail.WeatherDetailActivity
11-26 18:01:33.105   422   422 W         : debuggerd: resuming target 27906
11-26 18:01:33.105  1480  1509 I BootReceiver: Copying /data/tombstones/tombstone_06 to DropBox (SYSTEM_TOMBSTONE)
11-26 18:01:33.111   477   477 E lowmemorykiller: Error writing /proc/27906/oom_score_adj; errno=22
11-26 18:01:33.130   527   527 I Zygote  : Process 27906 exited due to signal (6)
11-26 18:01:33.131  1480 27154 I ActivityManager: Process no.nrk.yr (pid 27906) has died
11-26 18:01:33.131  1480 27154 D ActivityManager: cleanUpApplicationRecord -- 27906
wico commented 6 years ago

Appendix:

Starting with cmd package compile --reset no.nrk.yr (= app works):

If I wait a while (thus, a usage profile exists, in case of YR just 2-3 min) and do a cmd package compile -m speed-profile -f no.nrk.yr, that file is created:

/data/app/no.nrk.yr-2/oat/arm64/base.art (~700kb in size).

If it exists, the app crashes. If I remove it, app works instantly.

If I do a cmd package compile --reset no.nrk.yr and after that a cmd package compile -m speed-profile -f no.nrk.yr without waiting 2-3 min, a new (very small) /data/app/no.nrk.yr-2/oat/arm64/base.art get created (less functions compiled due to missing profile I guess) and the app does NOT crash.

If I do a cmd package compile --reset no.nrk.yr and after that a cmd package compile -m speed -f no.nrk.yr, a new (very big) /data/app/no.nrk.yr-2/oat/arm64/base.odex get created and the app does NOT crash. If I follow with a cmd package compile -m speed-profile -f no.nrk.yr, a very small /data/app/no.nrk.yr-2/oat/arm64/base.art and the /data/app/no.nrk.yr-2/oat/arm64/base.odex also shrinks in size (>50%) but the app still works after that.

So, my hope is: If I do a cmd package compile --reset -a followed by a cmd package compile -m speed -a, maybe the over-night "speed-profile" optimizing thingy has nothing to do, thus cant break stuff and all works fine. Lets see ...

wico commented 6 years ago

And this is finally a way to reproduce the issue:

Take an app, I suggest YR (no.nrk.yr) and do a rm /data/app/no.nrk.yr-2/oat/arm64/*. After that, play with the different compiler-settings and whatnot.

Make it crashing: 1) rm /data/app/no.nrk.yr-2/oat/arm64/* 2) Open app, wait 3 min 3) Close app 4) cmd package compile -m speed-profile -f no.nrk.yr 5) It should crash now...

... make it working: 6) cmd package compile -m speed -f no.nrk.yr 7) It works now

...and crashing: 8) cmd package compile -m speed-profile -f no.nrk.yr 9) It crashes now

However, as soon as there is a .art with some reasonable size, app is crashing.

And so on ...

Again ... no guarantee :)

wico commented 6 years ago

Ready for more verbosity? :)

I think, the bad guy is that one: https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/pm/BackgroundDexOptService.java

dumpsys jobscheduler

[...]
  JOB #1000/800: d8d5658 android/com.android.server.pm.BackgroundDexOptService
    1000 tag=*job*/android/com.android.server.pm.BackgroundDexOptService
    Source: uid=1000 user=0 pkg=android
    JobInfo:
      Service: android/com.android.server.pm.BackgroundDexOptService
      PERIODIC: interval=+1d0h0m0s0ms flex=+1d0h0m0s0ms
      Requires: charging=true deviceIdle=true
      Backoff: policy=1 initial=+30s0ms
      Has early constraint
      Has late constraint
    Required constraints: CHARGING TIMING_DELAY DEADLINE IDLE
    Satisfied constraints: TIMING_DELAY APP_NOT_IDLE
    Unsatisfied constraints: CHARGING DEADLINE IDLE
    Earliest run time: -12:52:52
    Latest run time: 11:07:07
    Ready: false (job=false pending=false active=false user=true)
[...]

And it should be possible to disable this systemservice, thus no profile-guided .art compilation is done anymore (hopefully). Still: no guarantee :)

rovo89 commented 6 years ago

Thanks for all your tests. I could meanwhile trigger a few different crashes with XPrivacy installed, especially when I compile the debug version of ART. I have since then started to use more GC-aware coding in some places, but I have yet to test whether this actually helps.

What I really want to avoid are guides that say "set this property and disable this service, that will fix it" - because actually, all of these would just be workarounds which might impact performance, no real fixes. And those guides usually stay around for a long time, even after the root cause has been fixed.

wico commented 6 years ago

I agree, e.g. disabling BackgroundDexOptService is not a fix. Unfortunately, XPrivacy is not under active development anymore - thus, it might come the situation a "workaround" is needed rather then losing the complete functionality. Or - you are able to find something on the XPosed side, that would be incredible awesome!

However, I just wanted to share my findings in a transparent and verbose way. :)

rovo89 commented 6 years ago

I'm pretty sure that this is on the Xposed/ART side. No module should be able to trigger native crashes just by using the official APIs.

StefanGitter commented 6 years ago

Hi, I am using Xposed 88.2 (Systemless by topjohnwu) as module in Magisk 14.0. To get this running without bootloops on my Galaxy S8 (SM-G950F), I installed the following Kernel: BatStock-Kernel_SM-G95XX_V1.6.0 (SeLinux is set to permissive).

Apart from a few force closes from time to time (mostly Google Play Services), Xposed runs smoothly. But after 1-2 days WhatsApp cannot be started anymore (it starts up with a white screen and hangs). I found out, that I can fix this by wiping the ART cache in my TWRP Recovery, so the issue seems to be related to the ART cache. As soon as the issue happens again, I will provide a log.

daibaron commented 6 years ago

Hi, i'm also having the same issue with a Galaxy S8 stock ROM. after the apps crashed the only way for me to have them working again is to resinstall the apps. I tried to wipe Dalvik cache (in stock recovery / no TWRP) after the crash but i won't repair anything.

StefanGitter commented 6 years ago

Hi,

The WhatsApp crash, as described in my comment above, happened again.

As promised, here is the Xposed log directly after the issue appeared: xposed_error_20171128_192802.log

I hope this helps to find the root-cause. If you need anything else, just tell me.

ElminsterAU commented 6 years ago

Just to add another datapoint.

I'm seeing crashes that look very much identical to the ones reported in this issue. (I found this thread by googeling for "myfitnesspal found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal".)

I'm running:

https://forum.xda-developers.com/axon-7/development/rom-dark-rom-t3654264 LineageOS Version: '14.1-20171102-NIGHTLY-axon7' Magisk 14.0 XPosed 88.2 (via the Systemless XPosed Magisk Module)

I have a lot of modules active in XPosed, but NOT XPrivacy.

Droidphilev commented 6 years ago

Hi,

i think the problem will be that Rovo will ignore this because teh systemless version is not the official version of Xposed.

ElminsterAU commented 6 years ago

His comments from 4 days ago do not sound like he's ignoring it. Also, given everything I've read in this issue here and can see in the logs of my phone, I very much doubt that this issue is limited to the systemless version.

StefanGitter commented 6 years ago

This is not dependent on the systemless version. The same happened on my device with the official version. That was actually the reason why I switched to the systemless version, just to find out that the same issue also exists here.

wico commented 6 years ago

Systemless or not, its the same error:

Abort message: 'art/runtime/class_linker.cc:2728] Check failed: found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal android.icu.math.BigDecimal.toBigDecimal()'

Can you please check if the BackgroundDexOptService was kicking in to create the .art files?

ElminsterAU commented 6 years ago

I have a complete verbose logcat dump where this error happened within 20 minutes after I rebooted after using TWRP to wipe cache and dalvik-cache.

Searching for BackgroundDexOptService shows: 12-02 02:16:07.857 1854 1854 I SystemServer: StartBackgroundDexOptService

the crash happend here: 12-02 02:32:33.809 11741 11741 F DEBUG : Abort message: 'art/runtime/class_linker.cc:2728] Check failed: found_virtual Didn't find oat method index for virtual method: java.math.BigDecimal android.icu.math.BigDecimal.toBigDecimal()'

ElminsterAU commented 6 years ago

some other suspicious looking art entries are:

12-02 02:33:37.247 12319 12352 F art : art/runtime/stack.cc:848] Check failed: instrumentationframe.method == GetMethod() (instrumentationframe.method=0x6f90f898, GetMethod()=0x7f6b4f2bd8) Expected: java.lang.Class java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) [XposedHooked] Found: java.lang.Class java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) [XposedOriginal]

12-02 02:34:41.952 12553 12563 F art : art/runtime/gc/collector/mark_sweep.cc:415] Tried to mark 0x12d54350 not contained by any spaces

12-02 02:35:48.079 12692 12692 F art : art/runtime/stack.cc:205] Check failed: success Failed to read the this object in void ccc71.at.xposed.at_xposed_enabled.handleLoadPackage(de.robv.android.xposed.callbacks.XC_LoadPackage$LoadPackageParam)

there are only 3 or 4 Information level XPosed log entries in the while log that I don't think will add anything useful

Droidphilev commented 6 years ago

Hi,

I never told that only the systemless version has this problem. I'm using the official version and have the problem myself. I only wrote this because Rovo posted in some threads that he only supports the official version (replying to people who posted logs coming from the systemless version). That's what i only meant. :-)

OT though.

ElminsterAU commented 6 years ago

To make absolutely sure it's an Xposed issue (this is a new phone for me that I just setup and it was running Xposed right from the start) I disabled XPosed yesterday after I made the posts here. I have not had a single crash since then. Let me know if there is anything specific I can do to help track this down.

wico commented 6 years ago

So, I just did it now with the brutal hammer ... ;). I have patched away the BackgroundDexOptService in my own LineageOS-built. Now XPrivacy works like a charm (even after days with charging over night etc. pp.). I also see no "slow-downs" and other negative impacts.

ElminsterAU commented 6 years ago

Any idea if it's possible to kill it with pm hide or pm disable instead?

rovo89 commented 6 years ago

Analyzing these crashes is really hard, because a corrupted stack causes crashes in more or less random places, which have nothing to do with the root cause. Anyway, after spending many evenings debugging this, I found some things that cause problems. I've reported one of them to Google as I think it's a bug in AOSP, and fixed a problem that prevented methods loaded from .art images not to be invalidated. These two should fix most, if not all crashes I have seen in this thread. There's also a deadlock for which I still need to find a way to prevent it. Afterwards, I'll release a new version, so please don't waste too much time on workarounds.

ElminsterAU commented 6 years ago

I've just spend a whole week trying to track down a heisenbug (my normal job, nothing to do with android) so I think I've a pretty good idea how you feel.

Thanks for the progress report, I'm looking forward to trying out the next version then.

roizcorp commented 6 years ago

While I agree with @rovo89 workarounds tend to stick even if they issue is fixed, however it gets really annoying when a lot applications crash and I have to recompile them everytime (holding my breath with applying @wanam wrokaround.

When can we have a fix (in the form of 88.3)?

rovo89 commented 6 years ago

These crashes should be fixed with v89 which I released last night.