leakcanary
leakcanary copied to clipboard
Leaks caused by ActivityThread.sCurrentActivityThread
LeakTrace information
┬───
│ GC Root: System class
│
├─ android.app.ActivityThread class
│ Leaking: NO (a class is never leaking)
│ ↓ static ActivityThread.sCurrentActivityThread
│ ~~~~~~~~~~~~~~~~~~~~~~
├─ android.app.ActivityThread instance
│ Leaking: UNKNOWN
│ Retaining 5.5 MB in 3069 objects
│ mInitialApplication instance of com.yzsy.moyan.App
│ mSystemContext instance of android.app.ContextImpl
│ mSystemUiContext instance of android.app.ContextImpl
│ ↓ ActivityThread.mNewActivities
│ ~~~~~~~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 5.5 MB in 2210 objects
│ activity instance of com.yzsy.moyan.ui.activity.main.MainActivity with mDestroyed = false
│ ↓ ActivityThread$ActivityClientRecord.nextIdle
│ ~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 5.5 MB in 2196 objects
│ activity instance of com.yzsy.moyan.ui.activity.live.LiveAudienceActivity with mDestroyed = true
│ ↓ ActivityThread$ActivityClientRecord.activity
│ ~~~~~~~~
╰→ com.yzsy.moyan.ui.activity.live.LiveAudienceActivity instance
Leaking: YES (ObjectWatcher was watching this because com.yzsy.moyan.ui.activity.live.LiveAudienceActivity
received Activity#onDestroy() callback and Activity#mDestroyed is true)
Retaining 310.7 kB in 1296 objects
key = d6548d07-89d7-4469-88ce-590ad28c14c0
watchDurationMillis = 5279
retainedDurationMillis = 276
mApplication instance of com.yzsy.moyan.App
mBase instance of androidx.appcompat.view.ContextThemeWrapper
Can you provide the Android SDK version? Also do you have a recipe to reproduce?
Build.VERSION.SDK_INT: 29 AndroidX Version: 1.2.0 LeakCanary version : 2.7 Sorry, i have no idea how to reproduce the leak.All I know is that there will be a leak when I press the back button
Thx. So, this is an Android leak I spent time reporting in 2020: https://issuetracker.google.com/issues/161230418
But then they made the issue private so I have no idea what happened. From looking at the sources, it looks like it's probably still happening.
The gist of it is that any resumed activity is held until the main thread is idle, even if they get destroyed.
I even had a repro project: https://github.com/pyricau/neveridle
here's a rant: https://twitter.com/Piwai/status/1409419331738521603
Thank you for your reply!
Note: we probably can't do much to fix this, however we can do a better job of documenting it as a known leak now that I've gathered a lot more context
https://github.com/square/leakcanary/blob/main/shark-android/src/main/java/shark/AndroidReferenceMatchers.kt#L83
=> should update API version and details.
@wang642357 as for what you can do: this leak happens if the main thread is never idle, i.e. if something is constantly posting to the main thread. You might want to figure out why your app is never idle.
Yes,i am reviewing the code to try to fix the problem.
This problem can occur in almost every Activity in my project,it could be a long process.
Hello, did you solve it?
==================================== HEAP ANALYSIS RESULT ==================================== 1 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
9865 bytes retained by leaking objects
Signature: e1c76f00955a7d673de751fa83bd6a78af3abee8
┬───
│ GC Root: System class
│
├─ android.app.ActivityThread class
│ Leaking: NO (a class is never leaking)
│ ↓ static ActivityThread.sCurrentActivityThread
│ ~~~~~~~~~~~~~~~~~~~~~~
├─ android.app.ActivityThread instance
│ Leaking: UNKNOWN
│ Retaining 89.0 kB in 1553 objects
│ mInitialApplication instance of com.verdandi.money.app.base.App
│ mSystemContext instance of android.app.ContextImpl
│ mSystemUiContext instance of android.app.ContextImpl
│ ↓ ActivityThread.mNewActivities
│ ~~~~~~~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 64.3 kB in 1070 objects
│ activity instance of com.verdandi.money.ui.main.activity.MainActivity with mDestroyed = false
│ ↓ ActivityThread$ActivityClientRecord.nextIdle
│ ~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 63.5 kB in 1055 objects
│ activity instance of com.verdandi.money.ui.drawer.activity.NotificationsActivity with mDestroyed = true
│ ↓ ActivityThread$ActivityClientRecord.activity
│ ~~~~~~~~
╰→ com.verdandi.money.ui.drawer.activity.NotificationsActivity instance
Leaking: YES (ObjectWatcher was watching this because com.verdandi.money.ui.drawer.activity.NotificationsActivity
received Activity#onDestroy() callback and Activity#mDestroyed is true)
Retaining 9.9 kB in 337 objects
key = 89a44e3a-982a-4f59-88c6-26aaff7565ec
watchDurationMillis = 5976
retainedDurationMillis = 965
mApplication instance of com.verdandi.money.app.base.App
mBase instance of androidx.appcompat.view.ContextThemeWrapper
====================================
0 LIBRARY LEAKS
A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS
An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA
Please include this in bug reports and Stack Overflow questions.
Build.VERSION.SDK_INT: 29
Build.MANUFACTURER: Google
LeakCanary version: 2.8.1
App process name: com.clkj.moneyclub
Count of retained yet cleared: 3 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=38125,misses=98878,hitRate=27%]
RandomAccess[bytes=5481951,reads=98878,travel=24266361534,range=19062049,size=23882187]
Heap dump reason: 5 retained objects, app is visible
Analysis duration: 6374 ms
Heap dump file path: /data/user/0/com.clkj.moneyclub/cache/leakcanary/2022-07-23_08-46-57_697.hprof
Heap dump timestamp: 1658537227618
Heap dump duration: 2064 ms
====================================
Filed it again: https://issuetracker.google.com/issues/258390457
Going forward this leak will be reported by LeakCanary as a known library leak.
┬───
│ GC Root: System class
│
├─ android.app.ActivityThread class
│ Leaking: NO (a class is never leaking)
│ ↓ static ActivityThread.sCurrentActivityThread
│ ~~~~~~~~~~~~~~~~~~~~~~
├─ android.app.ActivityThread instance
│ Leaking: UNKNOWN
│ Retaining 20.2 kB in 403 objects
│ mInitialApplication instance of com.zlcdgroup.mrmsei.App
│ mSystemContext instance of android.app.ContextImpl
│ mSystemUiContext instance of android.app.ContextImpl
│ ↓ ActivityThread.mActivities
│ ~~~~~~~~~~~
├─ android.util.ArrayMap instance
│ Leaking: UNKNOWN
│ Retaining 157 B in 5 objects
│ ↓ ArrayMap.mArray
│ ~~~~~~
├─ java.lang.Object[] array
│ Leaking: UNKNOWN
│ Retaining 64 B in 1 objects
│ ↓ Object[5]
│ ~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 500.7 kB in 9074 objects
│ activity instance of com.zlcdgroup.mrmsei.ui.metergroup.
│ MeterGroupEditActivity with mDestroyed = false
│ ↓ ActivityThread$ActivityClientRecord.nextIdle
│ ~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 500.0 kB in 9058 objects
│ activity instance of com.zlcdgroup.mrmsei.ui.media.
│ MediaAttributeNavEditActivity with mDestroyed = true
│ ↓ ActivityThread$ActivityClientRecord.activity
│ ~~~~~~~~
╰→ com.zlcdgroup.mrmsei.ui.media.MediaAttributeNavEditActivity instance
Leaking: YES (ObjectWatcher was watching this because com.zlcdgroup.
mrmsei.ui.media.MediaAttributeNavEditActivity received
Activity#onDestroy() callback and Activity#mDestroyed is true)
Retaining 419.7 kB in 8017 objects
key = 13d07004-14bd-4b5b-8cf3-790334a74469
watchDurationMillis = 5806
retainedDurationMillis = 786
mApplication instance of com.zlcdgroup.mrmsei.App
mBase instance of androidx.appcompat.view.ContextThemeWrapper
METADATA
Build.VERSION.SDK_INT: 28
Build.MANUFACTURER: Google
LeakCanary version: 2.11
App process name: com.zlcdgroup.mrmsei
Class count: 26166
Instance count: 268963
Primitive array count: 172340
Object array count: 34311
Thread count: 62
Heap total bytes: 28053582
Bitmap count: 45
Bitmap total bytes: 1415824
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/com.zlcdgroup.mrmsei/databases/mrmsei-db
Db 2: open /data/user/0/com.zlcdgroup.mrmsei/databases/mrmsei-db
Db 3: open /data/user/0/com.zlcdgroup.mrmsei/databases/bugly_db_
Db 4: open /data/user/0/com.zlcdgroup.mrmsei/no_backup/androidx.work.workdb
Db 5: open /data/user/0/com.zlcdgroup.mrmsei/databases/msre.db
Count of retained yet cleared: 2 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=69368,misses=184795,hitRate=27%]
RandomAccess[bytes=10262473,reads=184795,travel=85250294980,range=35655427,size=
44901611]
Analysis duration: 15444 ms
When I returned, I also received a lot of such leaks
See https://issuetracker.google.com/issues/258390457
You're running into this because your main thread is never idle. Figure out what message you're constantly posting to the main thread.