search

willowtreeapps / Hyperion-Android

App Debugging & Inspection Tool for Android
MIT License
1.95k stars 144 forks source link

Memory leak trouble #224

Closed adeldolgov closed 2 years ago

adeldolgov commented 3 years ago

Hello! Im using Hyperion 0.9.32 and i found next trouble:

  1. debugImplementation "com.willowtreeapps.hyperion:hyperion-core:0.9.32"
  2. Create two activity, use ViewBinding (i created empty activities for test, it leaks anyway)
  3. Go to second activity from first
  4. Press back navigation button, then wait around 10 sec, LeakCanary will show notification.
dsuresh-ap commented 3 years ago

I think this might be the same leak on v0.9.33:

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

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

    1473 bytes retained by leaking objects
    Signature: be48dca4a2a65b2856d568cd714c8daa2d7e776
    ┬───
    │ GC Root: Global variable in native code
    │
    ├─ com.willowtreeapps.hyperion.core.internal.HyperionService$Binder instance
    │    Leaking: UNKNOWN
    │    Retaining 528 B in 1 objects
    │    this$0 instance of com.willowtreeapps.hyperion.core.internal.HyperionService
    │    ↓ HyperionService$Binder.this$0
    │                             ~~~~~~
    ╰→ com.willowtreeapps.hyperion.core.internal.HyperionService instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.willowtreeapps.hyperion.core.internal.HyperionService
    ​     received Service#onDestroy() callback and Service not held by ActivityThread)
    ​     Retaining 1.5 kB in 11 objects
    ​     key = f458b12b-ce8e-49d5-bd7c-b45b0e6b7c04
    ​     watchDurationMillis = 29223
    ​     retainedDurationMillis = 24222
    ​     mApplication instance of com.app
    ​     mBase instance of android.app.ContextImpl
    ====================================
    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: samsung
    LeakCanary version: 2.7
    App process name: com.app
    Stats: LruCache[maxSize=3000,hits=3267,misses=72405,hitRate=4%]
    RandomAccess[bytes=3870688,reads=72405,travel=28545796796,range=22261409,size=27832566]
    Heap dump reason: 1 retained objects, app is not visible
    Analysis duration: 4759 ms
    Heap dump file path: /data/user/0/com.app/cache/leakcanary/2021-07-15_16-57-07_609.hprof
    Heap dump timestamp: 1626382638061
    Heap dump duration: 5629 ms
    ====================================
ToxicBakery commented 3 years ago

Yep, looks the same or similar to #220

el-fasoh commented 3 years ago

I have the same on 0.9.33

vincentbrison commented 3 years ago

Also having the same leak in 0.9.33

k-tomoyasu commented 3 years ago

It may be related that inner class Binder has implicit reference to outer class HyperionService.
I made Binder class stand-alone public class that has WeakReference to HyperionService class,
it seems to works fine.

Binder.java

final class Binder extends android.os.Binder {
        private final WeakReference<HyperionService> service;

        HyperionService getService() {
            return service.get();
        }

        Binder(final HyperionService service) {
            this.service = new WeakReference<>(service);
        } 
}

Following stackoverflow suggest similar issue.