Open Zedorff opened 3 years ago
I too am experiencing this issue with the same Glide version and the exact same stack trace, on a variety of different Android 9 and Android 10 devices. This crash has happened on 90 different devices of various types, though unfortunately I do not have a way to reproduce it.
I am using Glide in combination with the Firebase UI Storage library: com.firebaseui:firebase-ui-storage:6.2.0
.
Any help or workaround that would avoid crashing the app would be appreciated!
This bug was caused by cached items reporting varying sizes over their lifetimes, and has been fixed by https://github.com/bumptech/glide/commit/5090b6d004fabbc0ae50e0295fd50e2f13cb6357 . This isn't part of the latest release yet, but anyone struggling with this issue can fix this by using the bleeding edge version (http://bumptech.github.io/glide/dev/snapshots.html) instead.
This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.
Glide Version: 4.12.0
Device/Android Version: avd api 30
Issue details / Repro steps / Use case background: when back to home/launcher ,ontrim called ,it happened.
Stack trace / LogCat:
E/AndroidRuntime: FATAL EXCEPTION: main Process: com.android.enuos.sevenle, PID: 16911 java.util.NoSuchElementException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:759) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:790) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:788) at com.bumptech.glide.util.LruCache.trimToSize(LruCache.java:184) at com.bumptech.glide.load.engine.cache.LruResourceCache.trimMemory(LruResourceCache.java:56) at com.bumptech.glide.Glide.trimMemory(Glide.java:717) at com.bumptech.glide.Glide.onTrimMemory(Glide.java:925) at android.app.Application.onTrimMemory(Application.java:287) at android.app.ActivityThread.handleTrimMemory(ActivityThread.java:6256) at android.app.ActivityThread.access$1100(ActivityThread.java:237) at android.app.ActivityThread$ApplicationThread.lambda$scheduleTrimMemory$0(ActivityThread.java:1619) at android.app.-$$Lambda$ActivityThread$ApplicationThread$tUGFX7CUhzB4Pg5wFd5yeqOnu38.accept(Unknown Source:8) at com.android.internal.util.function.pooled.PooledLambdaImpl.doInvoke(PooledLambdaImpl.java:278) at com.android.internal.util.function.pooled.PooledLambdaImpl.invoke(PooledLambdaImpl.java:201) at com.android.internal.util.function.pooled.OmniFunction.run(OmniFunction.java:97) at android.view.Choreographer$CallbackRecord.run(Choreographer.java:972) at android.view.Choreographer.doCallbacks(Choreographer.java:796) at android.view.Choreographer.doFrame(Choreographer.java:733) at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:957) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:223) at android.app.ActivityThread.main(ActivityThread.java:7656) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
+1
The same is coming for DiskLruCache
for different libraries and most of them have to try catching it. Can we do the same for Glide.
One reason, I see for the same is for multi-process applications.
okhttp3.internal.cache.DiskLruCache.trimToSize (DiskLruCache.java:684)
Glide Version: 4.11.0
Device/Android Version: Variety of devices
Issue details / Repro steps / Use case background: We see a lot of crash reports in Firebase crashlytics. On 91% of devices this happens in background, approximate free RAM is 1GB+.
Stack trace / LogCat: