-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another leak in EditText #1610
Comments
🙏Thank you for opening an issue! LeakCanary is maintained by volunteers from the community. Please be kind and remember that LeakCanary isn't anyone's main job 😘. |
So it's only happening when the debugger/profiler/whatever is attached and doesn't happen i production, right? |
LeakCanary as of v2.0+ can only be used as a debugImplementation in gradle and is not installed in release artifacts. Thats why you may not see these logs in production but that doesn't mean the leak is gone, if this is what you mean.
|
Recently a popular app decided My point is that
sounds like it's connected to Android Studio. That wouldn't be a concern in production. This definitely is a library/Android SDK leak, I'm just pitching information for the leak description. |
@consp1racy Then I would say I must test its release version as well before commenting on that. |
That's a totally different leak, just follow the trace. C'mon, if LeakCanary says it's a different leak then it is a different leak. Have some trust, it's the tool's job, it's been doing that for years. |
Yeah, obviously I trust LeakCanary that's why I use it. But what makes me doubtful is that how could a leak can disappear in a similar implementation with same config. If you see, these two leaks are different but the one disappears in the other implementation. |
Anyways @consp1racy this issue doesn't seem to comply with what you said and I neither find anything good with your statement in the official LeakCanary documentation as well.
|
And not just the concerned one but as per my test LeakCanary is not able to trace any single leak in my release builds! This includes the one I mentioned earlier. |
A few notes:
|
Thanks @pyricau for your points they are always helpful.
I can share the hprof if that could help.
And Yup, I tested the release build with The last thing I am still wondering is that how is it possible for a library leak to go away in one project and present in the other?(I tested this with same configs and same device in release build and the library leak is present as expected) |
This isn't the same leak. Here the problem most likely comes from |
I think you got me wrong. Let me clarify.
Tell me if I am wrong? |
Sorry, I'm confused, I don't really follow. The leak trace you shared at the top is related to the profiler. Are you saying its not? |
No, you are absolutely right! |
I'm really sorry but I'm completely lost. You initially shared a single leak, which was classified as Application Leak. I don't understand which one is "the other one", how it's a library leak and what it has to do with the profiler leak. |
Just look at the trace here and compare it with the above one. Even though these two are completely different, you will find few points common:
While the leak trace here is an application leak and only exists in non prod, the other (I just referred above) is a library leak. |
Thanks! I understand now. A few things to consider:
Here the leaktraces are fairly different so this is probably two distinct bugs (or it could be some more general issue with InputMethodManager). |
Ok, thanks for all of your points. Your first point hit me so well that I just tested my app one more time exactly the same way I tested this and I found that the other(referred) leak is still there and I was not able to see it earlier was all because of the lifecycle of the application as you mentioned as this one only occurs when you exit your application, not necessarily when Conclusion: Do not suppose that a leak is gone if it's not found. There could be another way/path to that. |
For the description I would add that |
I've created a repo where you can easily reproduce this leak on Samsung devices: https://github.com/dmytroKarataiev/TextInputLayout-MemoryLeak |
any solution for this leak, maybe how to avoid it appearing during development or make it silent? |
The leak reported by dmytro had already been filed and ignored here: #2300 The leak reported in this issue seemed to be related to plugin in the profiler, though not 100% sure. We don't have a consistent repro and aren't able to determine whether this is OEM specific, an AOSP leak, or a bug from code injected by the profiler, and whether that would have been fixed. The InputConnectionWrapper git history shows that there's been a leak fix, though that would have been merged way before this was reported here (so maybe the merge didn't work) https://cs.android.com/android-studio/platform/tools/base/+/71bb355cb98bfd5158188b2aa214958bbb72802c Closing for now, we can reopen if someone reproduces with recent tooling |
As discussed in here, this is another leak of
EditText
(or any other subclass of it) that does not get destroyed every time it gets focused and retains themContext
until the focus gets shifted to anotherEditText
. Please note thatmContext
is destroyed as soon as the focus gets shifted to anotherEditText
and again a newmContext
is retained.Let me know if more info needed.
LeakTrace information
Leak trace generated on API 23 LG Nexus 5 although when tested on higher versions the leak is gone.
Steps to reproduce: Simple just use an
EditText
anywhere inside activity and make sure it's focused and afterActivity.onDestroy()
you will get the leak.The text was updated successfully, but these errors were encountered: