Closed shyamkumarm closed 5 months ago
Hi @shyamkumarm thanks for reaching out. Would you please provide the steps to reproduce this or reproduce it in a sample app and share it ?
Steps given below :
Let me know if you have any questions.
Note: However, The leaks never identified when I commented the line below (Disabling screenshot by Media Projection) //BugReporting.setScreenshotByMediaProjectionEnabled(true);
0 LIBRARY 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: 30 Build.MANUFACTURER: unknown LeakCanary version: 2.10 App process name: com.dev_0 Class count: 28404 Instance count: 198756 Primitive array count: 133699 Object array count: 29922 Thread count: 133 Heap total bytes: 26763359 Bitmap count: 2 Bitmap total bytes: 4102 Large bitmap count: 0 Large bitmap total bytes: 0 Db 1: open /data/user/0/com.dev_0/databases/ibg_diagnostics.db Db 2: open /data/user/0/com.dev_0/databases/instabug_encrypted.db Db 3: open /data/user/0/com.dev_0/databases/instabug.db Count of retained yet cleared: 33 KeyedWeakReference instances Stats: LruCache[maxSize=3000,hits=64922,misses=152428,hitRate=29%] RandomAccess[bytes=7816661,reads=152428,travel=72708959684,range=30602794,size=39711810] Heap dump reason: 23 retained objects, app is visible
@shyamkumarm Thank you for providing the steps, the fix for this leak will be included in our next release
Added the leak canary log given below,
Instabug android lib version: "11.10.0"
HEAP ANALYSIS RESULT
1 APPLICATION LEAKS
References underlined with "~~~" are likely causes. Learn more at https://squ.re/leaks.
709136 bytes retained by leaking objects Signature: bdf4f1db7c488b7befdb0bf860958ee920b04962 ┬─── │ GC Root: Thread object │ ├─ Tt instance │ Leaking: NO (PathClassLoader↓ is not leaking) │ Thread name: 'CleanupReference' │ ↓ Thread.contextClassLoader ├─ dalvik.system.PathClassLoader instance │ Leaking: NO (f↓ is not leaking and A ClassLoader is never leaking) │ ↓ ClassLoader.runtimeInternalObjects ├─ java.lang.Object[] array │ Leaking: NO (f↓ is not leaking) │ ↓ Object[5121] ├─ com.instabug.library.screenshot.f class │ Leaking: NO (a class is never leaking) │ ↓ static f.c │ ~ ├─ com.instabug.library.screenshot.f instance │ Leaking: UNKNOWN │ Retaining 709.2 kB in 14097 objects │ ↓ f.a │ ~ ├─ com.instabug.library.screenshot.d instance │ Leaking: UNKNOWN │ Retaining 709.2 kB in 14096 objects │ ↓ d.a │ ~ ├─ com.instabug.library.screenshot.e instance │ Leaking: UNKNOWN │ Retaining 709.2 kB in 14095 objects │ ↓ e.a │ ~ ├─ com.instabug.library.core.InitialScreenshotHelper$a instance │ Leaking: UNKNOWN │ Retaining 709.2 kB in 14094 objects │ a instance of com.ui.MainActivity with mDestroyed = true │ ↓ InitialScreenshotHelper$a.a │ ~ ╰→ com.ui.MainActivity instance Leaking: YES (ObjectWatcher was watching this because com.ui.MainActivity received Activity#onDestroy() callback and Activity#mDestroyed is true) Retaining 709.1 kB in 14092 objects key = 1895db29-63d7-4473-a009-9625ccbb9169 watchDurationMillis = 5593 retainedDurationMillis = 588 mApplication instance of com.app.MainApplication 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