Leak in EditText

[OsBelief]

I have following leak on Android 6.0.1 on Moto G4.
In com.czh.share:0.0.1:1.

• com.czh.share.AccountSettingsActivity has leaked:
• GC ROOT thread java.lang.Thread. (named 'AsyncTask Leak in SpellCheckerSession. #4')
• references android.os.AsyncTask$SerialExecutor$1.this$0 (anonymous implementation of java.lang.Runnable)
• references android.os.AsyncTask$SerialExecutor.mTasks
• references java.util.ArrayDeque.elements
• references array java.lang.Object[].[2]
• references android.os.AsyncTask$SerialExecutor$1.val$r (anonymous implementation of java.lang.Runnable)
• references android.widget.TextView$3.this$0 (anonymous implementation of java.lang.Runnable)
• references android.widget.EditText.mContext
• leaks com.czh.share.AccountSettingsActivity instance
• Reference Key: 5e941d29-afb4-470a-99a9-e34cd80f1aae
• Retaining: 2.7 KB.
• Android Version: 6.0.1 API: 23 LeakCanary: 1.5 00f37f5
• Durations: watch=5024ms, gc=191ms, heap dump=2873ms, analysis=37033ms

[jrodbx]

Looks like you're referencing an EditText from an AsyncTask and leaking Context. If this is still happening, can you provide the snippet of code?

[jrodbx]

No response. Please re-open if you see this issue again and can provide more info.

[dimsuz]

FYI: This was analyzed in this issue: intercom/intercom-android#368, and it seems like this is the leak inside a TextView itself. Perhaps this should be added to the exclusions file.

[DeweyReed]

I get this leak too. It caused internally by TextView's AsyncTask updateTextServicesLocaleAsync.

Perhaps this should be added to the exclusions file. +1

Update

This happens from time to time and a simple empty EditText can also cause the leak. I guess it's probably because network issues.

Exclude it by replacing LeakCanary.install(this) with

LeakCanary.refWatcher(this)
    .excludedRefs(AndroidExcludedRefs.createAppDefaults()
        .instanceField("android.widget.TextView$3", "this$0")
        .build())
    .buildAndInstall()

[Guneetgstar]

I've been messing with this leak this whole week and finally, I have enough evidence to say that EditText(or any sub-class) does not get destroyed every time it gets focused and retains the mContext until the focus gets shifted to another EditText. Please note that mContext is destroyed as soon as the focus gets shifted to another EditText and again a new mContext is retained.
@DeweyReed As you suggested to exclude it, this doesn't work in the #1211 as "no-op" dependency has been removed (#1218). I figured out how to migrate to LeakCanary 2.0+ and added the following code in my Application class and that too didn't work(I'm still trying to figure out how to use instanceFieldLeak(className, fieldName) ) :-

LeakCanary.config = LeakCanary.config.copy(
                referenceMatchers = AndroidReferenceMatchers.appDefaults +
                        AndroidReferenceMatchers.instanceFieldLeak(
                                "com.colevit.furmate.AppHelper.customViews.AppEditText",
                                "this"
                        )
        )

A better option would be to put it in AndroidExcludedRefs
Here is the leak trace, let me know if anything else is required :-

ApplicationLeak(className=com.colevit.furmate.module.container.ContainerActivity, leakTrace=
┬
├─ java.lang.Thread
│    Leaking: UNKNOWN
│    Thread name: 'Studio:InputCon'
│    GC Root: Java local variable
│    ↓ thread Thread.<Java Local>
│                    ~~~~~~~~~~~~
├─ com.android.tools.profiler.support.event.InputConnectionWrapper
│    Leaking: UNKNOWN
│    ↓ InputConnectionWrapper.mTarget
│                             ~~~~~~~
├─ com.android.internal.widget.EditableInputConnection
│    Leaking: UNKNOWN
│    ↓ EditableInputConnection.mTargetView
│                              ~~~~~~~~~~~
├─ androidx.appcompat.widget.AppCompatEditText
│    Leaking: YES (View.mContext references a destroyed activity)
│    mContext instance of android.view.ContextThemeWrapper, wrapping activity com.colevit.furmate.module.container.ContainerActivity with mDestroyed = true
│    View#mParent is set
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 1
│    ↓ AppCompatEditText.mContext
├─ android.view.ContextThemeWrapper
│    Leaking: YES (AppCompatEditText↑ is leaking and ContextThemeWrapper wraps an Activity with Activity.mDestroyed true)
│    ↓ ContextThemeWrapper.mBase
╰→ com.colevit.furmate.module.container.ContainerActivity
​     Leaking: YES (ContextThemeWrapper↑ is leaking and Activity#mDestroyed is true and ObjectWatcher was watching this)
​     key = 618d2116-4c2d-4118-ab3a-a9b5d6f8ae68
​     watchDurationMillis = 7833
​     retainedDurationMillis = 2833
, retainedHeapByteSize=7447)

[Guneetgstar]

@jrodbx Please re-open the issue

No response. Please re-open if you see this issue again and can provide more info.

[jrodbx]

@Guneetgstar can you provide a small reproducible sample?

[Guneetgstar]

Simple just use an EditText anywhere inside activity and make sure it's focused and after Activity.onDestroy() you will get the leak.
I have set up a sample project that reproduces the issue here.

@Guneetgstar can you provide a small reproducible sample?

[Guneetgstar]

I just saw the LeakCanary debug logs and I found that this bug has already been identified and traced here with a fix but I am seeing this bug on API 23 LG Nexus 5 which as per the tracker is fixed.

[pyricau]

@Guneetgstar The leaktrace you provided is very different from the leaktrace the original author had provided, this is a different issue. It's also likely a different issue from the link you provided to the google tracker (input method manager has many leaks)

Can you open a new issue with the info you provided so that we can close that one back? The next step will likely be to add a reference matcher.

[Guneetgstar]

@Guneetgstar The leaktrace you provided is very different from the leaktrace the original author had provided, this is a different issue. It's also likely a different issue from the link you provided to the google tracker (input method manager has many leaks)

Can you open a new issue with the info you provided so that we can close that one back? The next step will likely be to add a reference matcher.

Sure the leak traces are different and before opening a new issue I want to show you the leak traces I just added in README.md of the sample project that reproduces the issue, it's again a different trace but it refers to the issue whose link I added in my last comment. So if it's about the different leak traces than I must open two new issues now but the thing is both the leak traces were produced doing the same thing, with README.md trace giving more info.

[pyricau]

Ha! Thanks for that, I had missed the readme.

See this?

applicationLeaks=[], libraryLeaks=[LibraryLeak(...

It means the two leaks that were found were correctly identified by leakcanary as "library leaks", ie known android leaks. I'm not sure what else we should do here?

[pyricau]

(note: we should probably make it clearer in the leaktrace what app vs lib leaks are)

[Guneetgstar]

I can see clearly that this leak is identified by LeakCanary and although, with that huge description and links in it this should be clear to everyone.
But am I supposed to see this library leak? Do LeakCanary report all the library leaks?
I guess I shouldn't be seeing them as being an application developer I can't do anything about it.

Ha! Thanks for that, I had missed the readme.

See this?

applicationLeaks=[], libraryLeaks=[LibraryLeak(...

It means the two leaks that were found were correctly identified by leakcanary as "library leaks", ie known android leaks. I'm not sure what else we should do here?

[Guneetgstar]

@pyricau What I wanted to convey with README.md is that both the leak trace in README.md and the leak trace I posted here is due to the same library leaks because I am trying to do the same thing in both the applications but the traces are different. Isn't that possible because I also tested both application on higher versions where the leak is fixed and it's not identified there in both the apps?

[pyricau]

Yes it's likely these are two different leaks, they're just both triggered by the same actions.

As for reporting library leaks, LeakCanary has no way to know until the analysis is performed. If we stopped reporting them then devs would be confused, asking what happened with the leak. Also, library leaks can indeed by fixed, though it's harder. For instance by using reflection or finding other ways to cause the leak to clear.

[Guneetgstar]

Thanks @pyricau I have created a new issue for this here. You may close it back now.