leakcanary icon indicating copy to clipboard operation
leakcanary copied to clipboard

Chromium Webview AwWindowCoverageTracker leaks activity (API 32/33, default image)

Open maksym-moroz opened this issue 1 year ago • 2 comments

LeakTrace information

┬───
│ GC Root: Global variable in native code
│
├─ dalvik.system.PathClassLoader instance
│    Leaking: NO (Na↓ is not leaking and A ClassLoader is never leaking)
│    ↓ ClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
│    Leaking: NO (Na↓ is not leaking)
│    ↓ Object[167]
├─ Na class
│    Leaking: NO (a class is never leaking)
│    ↓ static Na.e
│                ~
├─ java.util.HashMap instance
│    Leaking: UNKNOWN
│    Retaining 144.1 kB in 1546 objects
│    ↓ HashMap[key()]
│             ~~~~~~~
├─ com.android.internal.policy.DecorView instance
│    Leaking: YES (View.mContext references a destroyed activity)
│    Retaining 143.9 kB in 1540 objects
│    View not part of a window view hierarchy
│    View.mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    mContext instance of com.android.internal.policy.DecorContext, wrapping
│    activity com.example.webviewleak.MainActivity with mDestroyed = true
│    ↓ DecorView.mContentRoot
├─ android.widget.LinearLayout instance
│    Leaking: YES (DecorView↑ is leaking and View.mContext references a
│    destroyed activity)
│    Retaining 1.8 kB in 24 objects
│    View is part of a window view hierarchy
│    View.mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    mContext instance of com.example.webviewleak.MainActivity with mDestroyed
│    = true
│    ↓ View.mContext
╰→ com.example.webviewleak.MainActivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.example.
​     webviewleak.MainActivity received Activity#onDestroy() callback and
​     Activity#mDestroyed is true)
​     Retaining 1.2 kB in 33 objects
​     key = 2b39a17d-e07f-4c9c-83fa-786d5748ef2f
​     watchDurationMillis = 5310
​     retainedDurationMillis = 301
​     mApplication instance of android.app.Application
​     mBase instance of android.app.ContextImpl

METADATA

Build.VERSION.SDK_INT: 33
Build.MANUFACTURER: unknown
LeakCanary version: 2.14
App process name: com.example.webviewleak
Class count: 22975
Instance count: 174106
Primitive array count: 122664
Object array count: 22807
Thread count: 25
Heap total bytes: 23698747
Bitmap count: 5
Bitmap total bytes: 133125
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/com.example.webviewleak/databases/leaks.db
Stats: LruCache[maxSize=3000,hits=108299,misses=171449,hitRate=38%]
RandomAccess[bytes=8822750,reads=171449,travel=56481646684,range=28588994,size=3
5558996]
Analysis duration: 3357 ms

The library is obfuscated but following the structure of the webview library or debugging we can track down the leak to a static map inside AwWindowCoverageTracker class. Due to obfuscation stack traces are different for API32 and API33. Stacktrace attached above is for API 33, default image.

This only seems to happen on API 32/33, default image, I wasn't able to verify if it happens on aosp_atd images

Reproducible sample

https://github.com/maksym-moroz/webviewleak

maksym-moroz avatar Feb 13 '25 13:02 maksym-moroz

Any updates? If there is any additional info required I would be happy to provide or elaborate on any of this

maksym-moroz avatar Feb 27 '25 09:02 maksym-moroz

I just encountered this. On two devices both running Android 13 (so API 33), but different versions of Android System WebView (101.0.4951.61 vs 135.0.7049.99), this leak seems to only occur on the earlier version.

bbrk24 avatar Apr 22 '25 14:04 bbrk24