Memory leak according to LeakCanary
See original GitHub issuePlease complete the following information:
- Library Version: 1.2.0
- Affected Device(s): Xiaomi Poco F2 Pro
Describe the Bug:
Whenever I add a com.skydoves.powerspinner.PowerSpinnerView
to my fragment I get a notification from LeakCanary about a memory leak caused by the PowerSpinnerView. I donβt do anything else with it with code, itβs just this.
<com.skydoves.powerspinner.PowerSpinnerView
android:id="@+id/genreSpinner"
android:layout_width="80dp"
android:layout_height="wrap_content"
android:layout_margin="6dp"
android:hint="Genre"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"/>
I tried setting the lifecycleowner
genreSpinner.lifecycleOwner = this <- (Fragment)
With or without it, I still get the memory leak notification.
When I add the PowerSpinnerView
to my main activity layout file (my app uses 1 activity with multiple fragments) I donβt have this issue.
Expected Behavior: No memory leak π
Below you can see the notification from LeakCanary:
β¬βββ
β GC Root: Input or output parameters in native code
β
ββ android.os.FileObserver$ObserverThread instance
β Leaking: NO (PathClassLoaderβ is not leaking)
β Thread name: 'FileObserver'
β β Thread.contextClassLoader
ββ dalvik.system.PathClassLoader instance
β Leaking: NO (InternalLeakCanaryβ is not leaking and A ClassLoader is never
β leaking)
β β ClassLoader.runtimeInternalObjects
ββ java.lang.Object[] array
β Leaking: NO (InternalLeakCanaryβ is not leaking)
β β Object[].[378]
ββ leakcanary.internal.InternalLeakCanary class
β Leaking: NO (MainActivityβ is not leaking and a class is never leaking)
β β static InternalLeakCanary.resumedActivity
ββ <my_package>.MainActivity instance
β Leaking: NO (Activity#mDestroyed is false)
β mApplication instance of <my_package>.MainApplication
β mBase instance of androidx.appcompat.view.ContextThemeWrapper
β β ComponentActivity.mLifecycleRegistry
β ~~~~~~
ββ androidx.lifecycle.LifecycleRegistry instance
β Leaking: UNKNOWN
β Retaining 1.1 kB in 44 objects
β β LifecycleRegistry.mObserverMap
β ~~~~
ββ androidx.arch.core.internal.FastSafeIterableMap instance
β Leaking: UNKNOWN
β Retaining 932 B in 39 objects
β β SafeIterableMap.mEnd
β ~~
ββ androidx.arch.core.internal.SafeIterableMap$Entry instance
β Leaking: UNKNOWN
β Retaining 56 B in 3 objects
β β SafeIterableMap$Entry.mKey
β ~~
ββ com.skydoves.powerspinner.PowerSpinnerView instance
β Leaking: UNKNOWN
β Retaining 1.9 MB in 9635 objects
β View not part of a window view hierarchy
β View.mAttachInfo is null (view detached)
β View.mID = R.id.null
β View.mWindowAttachCount = 1
β mContext instance of <my_package>.MainActivity with mDestroyed =
β false
β β View.mParent
β ~~~
ββ androidx.constraintlayout.widget.ConstraintLayout instance
β Leaking: UNKNOWN
β Retaining 1.5 MB in 5099 objects
β View not part of a window view hierarchy
β View.mAttachInfo is null (view detached)
β View.mID = R.id.null
β View.mWindowAttachCount = 1
β mContext instance of <my_package>.MainActivity with mDestroyed =
β false
β β View.mParent
β ~~~
ββ androidx.constraintlayout.widget.ConstraintLayout instance
β Leaking: UNKNOWN
β Retaining 1.4 kB in 22 objects
β View not part of a window view hierarchy
β View.mAttachInfo is null (view detached)
β View.mID = R.id.null
β View.mWindowAttachCount = 1
β mContext instance of <my_package>.MainActivity with mDestroyed =
β false
β β View.mParent
β ~~~
β°β androidx.drawerlayout.widget.DrawerLayout instance
β Leaking: YES (ObjectWatcher was watching this because <my_package>.
β fragments.channelsFragment.ChannelsFragment received
β Fragment#onDestroyView() callback (references to its views should be
β cleared to prevent leaks))
β Retaining 3.2 kB in 91 objects
β key = b686def5-a840-41ef-931a-d2b1a1f03023
β watchDurationMillis = 15996
β retainedDurationMillis = 10996
β View not part of a window view hierarchy
β View.mAttachInfo is null (view detached)
β View.mID = R.id.null
β View.mWindowAttachCount = 1
β mContext instance of <my_package>.MainActivity with mDestroyed =
β false
METADATA
Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.7
App process name: <my_package>
Stats: LruCache[maxSize=3000,hits=3371,misses=114403,hitRate=2%]
RandomAccess[bytes=5538838,reads=114403,travel=56894977315,range=28893688,size=3
6090270]
Heap dump reason: user request
Analysis duration: 5416 ms
Issue Analytics
- State:
- Created a year ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
Fixing a memory leak - LeakCanary
A memory leak is a programming error that causes an application to keep a reference to an object that is no longer needed....
Read more >How to get rid of memory leaks? A practical approach using ...
1 . Detecting retained objects. LeakCanary hooks into the Android lifecycle and detects when activities and fragments are destroyed and should be garbageΒ ......
Read more >Memory Leaks in Android | Kodeco, the new raywenderlich.com
LeakCanary is a library designed to detect memory leaks. You'll learn what they are, common cases and how to avoid them. In this...
Read more >Sample application, memory leaks found by LeakCanary #1463
Memory leaks still happen once in a while, even with the WeakReference fix. According to https://square.github.io/leakcanary/fundamentals/:.
Read more >Do we still need LeakCanary now that Android Studio 3.6 has ...
The next thing we obviously want to do is to fix the leak. Memory leaks occur when references to βdeadβ objects that are...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi, you must use
viewLifecycleOwner
in your Fragment instead ofthis
.Fixed