Leakcanary: WindowManagerGlobal leaks LinearLayout.

Created on 28 Oct 2020  ·  7Comments  ·  Source: square/leakcanary

This leak looks similar to a leak which already gets distinguished as a Library leak:
https://github.com/square/leakcanary/blob/58ceeeb2da7c7a2bbeb39c41fd0d8b2c67b5e17b/shark-android/src/main/java/shark/AndroidReferenceMatchers.kt#L675

I'm not able to consistently reproduce this leak.

LeakTrace information

    ┬───
    │ GC Root: System class
    │
    ├─ android.view.WindowManagerGlobal class
    │    Leaking: NO (a class is never leaking)
    │    ↓ static WindowManagerGlobal.sDefaultWindowManager
    │                                 ~~~~~~~~~~~~~~~~~~~~~
    ├─ android.view.WindowManagerGlobal instance
    │    Leaking: UNKNOWN
    │    Retaining 643 bytes in 13 objects
    │    ↓ WindowManagerGlobal.mViews
    │                          ~~~~~~
    ├─ java.util.ArrayList instance
    │    Leaking: UNKNOWN
    │    Retaining 60 bytes in 2 objects
    │    ↓ ArrayList.elementData
    │                ~~~~~~~~~~~
    ├─ java.lang.Object[] array
    │    Leaking: UNKNOWN
    │    Retaining 40 bytes in 1 objects
    │    ↓ Object[].[0]
    │               ~~~
    ├─ android.widget.LinearLayout instance
    │    Leaking: YES (View.mContext references a destroyed activity)
    │    Retaining 5952 bytes in 31 objects
    │    View is part of a window view hierarchy
    │    View.mAttachInfo is not null (view attached)
    │    View.mWindowAttachCount = 1
    │    mContext instance of eu.unmatched.lynx.ui.activities.main.MainActivity with mDestroyed = true
    │    ↓ LinearLayout.mContext
    ╰→ eu.unmatched.lynx.ui.activities.main.MainActivity instance
    ​     Leaking: YES (ObjectWatcher was watching this because eu.unmatched.lynx.ui.activities.main.MainActivity received
    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
    ​     Retaining 95623 bytes in 1464 objects
    ​     key = 8da7d617-f46c-4f03-ba19-d9fe2bbcdb49
    ​     watchDurationMillis = 5189
    ​     retainedDurationMillis = 187
    ​     mApplication instance of eu.unmatched.lynx.MyApplication
    ​     mBase instance of androidx.appcompat.view.ContextThemeWrapper, not wrapping known Android context

    METADATA

    Build.VERSION.SDK_INT: 27
    Build.MANUFACTURER: POINTMOBILE
    LeakCanary version: 2.5
    App process name: eu.unmatched.lynx.lite
    Stats: LruCache[maxSize=3000,hits=1636,misses=38365,hitRate=4%]
    RandomAccess[bytes=1931040,reads=38365,travel=13137515160,range=12301429,size=15381381]
    Analysis duration: 11947 ms

2020-10-28_11-27-03_692.zip

good first issue help wanted leak
Source
picture mickverm

All 7 comments

👍 Looks like we need to add "android.view.WindowManagerGlobal", "mViews" to WINDOW_MANAGER_GLOBAL

pyricau picture pyricau on 31 Oct 2020
👍1

I took a deeper look into the heap dump (thanks for providing it!), as it seems surprising to see an attached view for a destroyed activity.

It turns out, the root view of the activity is actually detached. However, there are two extra root views that use the activity as their context but are still attached. Looking at the window attributes (title), both say "Toast".

Both toasts say "Event has been sent"

So I'm not sure this is a proper AOSP leak. Have you tried using the application context to create these toasts?

pyricau picture pyricau on 3 Dec 2020
👀1

Thanks for taking a deeper look into the heap dump. You might have just given me a way to reproduce this issue!
I didn't know a Toast would still be around if it had been shown using the Activity Context without being kept in a field.
I'll try to reproduce this and I'll get back to you!

mickverm picture mickverm on 3 Dec 2020

@pyricau

I was very easily able to reproduce the issue using the following project https://github.com/mickverm/Leaks on the emulator:

  1. Android 6.0 (SDK 23)
  2. Android 7.0 (SDK 24)
  3. Android 7.1.1 (SDK 25)
  4. Android 8.0 (SDK 26)

Produces a LeakTrace which seems to be WINDOW_MANAGER_GLOBAL in AndroidReferenceMatchers library leaks

    ====================================
    HEAP ANALYSIS RESULT
    ====================================
    1 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.

    53381 bytes retained by leaking objects
    Signature: 32422f35e5d511ca7a995eb137466491deb1b0
    ┬───
    │ GC Root: System class
    │
    ├─ android.view.WindowManagerGlobal class
    │    Leaking: NO (ViewRootImpl↓ is not leaking and a class is never leaking)
    │    ↓ static WindowManagerGlobal.sDefaultWindowManager
    ├─ android.view.WindowManagerGlobal instance
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ WindowManagerGlobal.mRoots
    ├─ java.util.ArrayList instance
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ ArrayList.elementData
    ├─ java.lang.Object[] array
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ Object[].[1]
    ├─ android.view.ViewRootImpl instance
    │    Leaking: NO (ViewRootImpl#mView is not null)
    │    mContext instance of be.mickverm.leaks.ui.activities.MainActivity with mDestroyed = true
    │    ↓ ViewRootImpl.mContext
    │                   ~~~~~~~~
    ╰→ be.mickverm.leaks.ui.activities.MainActivity instance
    ​     Leaking: YES (ObjectWatcher was watching this because be.mickverm.leaks.ui.activities.MainActivity received
    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
    ​     Retaining 53381 bytes in 809 objects
    ​     key = 00f5f718-350d-4ecc-ba1d-ef2d8d404dc8
    ​     watchDurationMillis = 5117
    ​     retainedDurationMillis = 116
    ​     mApplication instance of android.app.Application
    ​     mBase instance of android.app.ContextImpl, not wrapping known Android context
    ====================================
    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
    ====================================
    METADATA

    Please include this in bug reports and Stack Overflow questions.

    Build.VERSION.SDK_INT: 26
    Build.MANUFACTURER: Google
    LeakCanary version: 2.5
    App process name: be.mickverm.leaks
    Stats: LruCache[maxSize=3000,hits=1864,misses=28143,hitRate=6%]
    RandomAccess[bytes=1572782,reads=28143,travel=5563280504,range=7844522,size=9953547]
    Analysis duration: 1643 ms
    Heap dump file path: /data/user/0/be.mickverm.leaks/files/leakcanary/2020-12-03_12-50-02_580.hprof
    Heap dump timestamp: 1606996204693
    Heap dump duration: 457 ms
    ====================================
  1. Android 8.1 (SDK 27)

Produces the LeakTrace attached in https://github.com/square/leakcanary/issues/1982#issue-731336879

  1. Android 9.0 (SDK 28)

Was unable to cause a leak.

  1. Android 10.0 (SDK 29)
  2. Android 11.0 (SDK 30)

Produced leak cfr. SDK 23-26 and a known library leak.

    ====================================
    HEAP ANALYSIS RESULT
    ====================================
    1 APPLICATION LEAKS

    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.

    45547 bytes retained by leaking objects
    Signature: 32422f35e5d511ca7a995eb137466491deb1b0
    ┬───
    │ GC Root: System class
    │
    ├─ android.view.WindowManagerGlobal class
    │    Leaking: NO (ViewRootImpl↓ is not leaking and a class is never leaking)
    │    ↓ static WindowManagerGlobal.sDefaultWindowManager
    ├─ android.view.WindowManagerGlobal instance
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ WindowManagerGlobal.mRoots
    ├─ java.util.ArrayList instance
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ ArrayList.elementData
    ├─ java.lang.Object[] array
    │    Leaking: NO (ViewRootImpl↓ is not leaking)
    │    ↓ Object[].[0]
    ├─ android.view.ViewRootImpl instance
    │    Leaking: NO (ViewRootImpl#mView is not null)
    │    mContext instance of be.mickverm.leaks.ui.activities.MainActivity with mDestroyed = true
    │    ↓ ViewRootImpl.mContext
    │                   ~~~~~~~~
    ╰→ be.mickverm.leaks.ui.activities.MainActivity instance
    ​     Leaking: YES (ObjectWatcher was watching this because be.mickverm.leaks.ui.activities.MainActivity received
    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
    ​     Retaining 45547 bytes in 822 objects
    ​     key = 18a52c98-0f5d-437f-a966-1c7053315628
    ​     watchDurationMillis = 29933
    ​     retainedDurationMillis = 24931
    ​     mApplication instance of android.app.Application
    ​     mBase instance of android.app.ContextImpl, not wrapping known Android context
    ====================================
    1 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

    Leak pattern: native global variable referencing android.widget.Toast$TN
    Description: Toast.TN is held by a global variable in native code due to an IPC call to show the toast.
    90946 bytes retained by leaking objects
    Displaying only 1 leak trace out of 2 with the same signature
    Signature: 57b73389f44769aaf18fc472c6d6be789fe3191
    ┬───
    │ GC Root: Global variable in native code
    │
    ├─ android.widget.Toast$TN instance
    │    Leaking: UNKNOWN
    │    Retaining 3270 bytes in 26 objects
    │    ↓ Toast$TN.mNextView
    │               ~~~~~~~~~
    ├─ android.widget.LinearLayout instance
    │    Leaking: YES (View.mContext references a destroyed activity)
    │    Retaining 2459 bytes in 22 objects
    │    View not part of a window view hierarchy
    │    View.mAttachInfo is null (view detached)
    │    View.mWindowAttachCount = 0
    │    mContext instance of be.mickverm.leaks.ui.activities.MainActivity with mDestroyed = true
    │    ↓ LinearLayout.mContext
    ╰→ be.mickverm.leaks.ui.activities.MainActivity instance
    ​     Leaking: YES (ObjectWatcher was watching this because be.mickverm.leaks.ui.activities.MainActivity received
    ​     Activity#onDestroy() callback and Activity#mDestroyed is true)
    ​     Retaining 45473 bytes in 824 objects
    ​     key = e0d19f5a-df5f-4e5b-9b2e-ad6ea023ba3c
    ​     watchDurationMillis = 14176
    ​     retainedDurationMillis = 9172
    ​     mApplication instance of android.app.Application
    ​     mBase instance of android.app.ContextImpl, not wrapping known Android context

    ====================================
    METADATA

    Please include this in bug reports and Stack Overflow questions.

    Build.VERSION.SDK_INT: 29
    Build.MANUFACTURER: Google
    LeakCanary version: 2.5
    App process name: be.mickverm.leaks
    Stats: LruCache[maxSize=3000,hits=3431,misses=41917,hitRate=7%]
    RandomAccess[bytes=2140317,reads=41917,travel=10576390520,range=12326178,size=16436075]
    Analysis duration: 8922 ms
    Heap dump file path: /data/user/0/be.mickverm.leaks/files/leakcanary/2020-12-03_13-16-55_691.hprof
    Heap dump timestamp: 1606997826896
    Heap dump duration: 2
mickverm picture mickverm on 3 Dec 2020
👍1

And yes, using requireContext().applicationContext resolves this leak.

mickverm picture mickverm on 3 Dec 2020

Interesting! Thx for the repro. So enqueuing toasts with activity context can create this leak. And because toasts stay in the queue until rendered, this could take a while.

pyricau picture pyricau on 3 Dec 2020

Ok, I've looked into this some more. Thanks for the repro case again, that really helped.

It's our job as developers to make sure we either use an application context, or cancel toasts when the activity is destroyed (see https://twitter.com/Piwai/status/1334551845000253442). If we use the activity context, then we need to cancel the toast on destroy, and if we don't we get this leak.

The WINDOW_MANAGER_GLOBAL tagging of android.view.WindowManagerGlobal#mRoots as a LibraryLeak was a mistake of mine: this isn't really a library leak, i.e. a bug in AOSP. I added this tagging only to API 27. LeakCanary tries to find a path that doesn't go through any such tag, which is why on API 27 is went through the longer path via android.view.WindowManagerGlobal#mViews.

I'll remove this tag, and add more details to help surface these leaks.

pyricau picture pyricau on 3 Dec 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

devism picture devism  ·  6Comments
nobeh picture nobeh  ·  5Comments
msfjarvis picture msfjarvis  ·  6Comments
edgelv34 picture edgelv34  ·  7Comments
matejdro picture matejdro  ·  6Comments