-
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
Leak in SpellCheckerSession. #4
Comments
Cool, I thought it was a motorola only thing: https://github.com/square/leakcanary/blob/master/library/leakcanary-android/src/main/java/com/squareup/leakcanary/AndroidExcludedRefs.java#L216 Next steps:
|
Oh I should have to look at this file first. |
Can't we update AndroidExcludedRefs at first? |
Yes. I like to figure out the issue first (when it's worth it), so that I don't just hide it under the rug. But we can also just ignore this guy. |
@pepyakin Before I file an issue on Android, what is InterceptEditText doing? Is it messing with the edit text content in some way, maybe the spell checker or the Editor? This leak could happen if SpellChecker.close() isn't correctly called. It's normally called when the textview is detached, which itself calls Editor.onDetach which closes the SpellChecker which should end up closing the SpellCheckSession and clearing the mHandler field in SpellCheckerSessionListenerImpl |
@pyricau , OK, I see. |
Thanks! Could you send me the heap dump file, maybe as a dropbox or google drive link? I'm trying to figure this out. I need to access the state of some of the intermediary objects. Here's my "bug report" draft : SpellCheckerSessionListenerImpl.mHandler is leaking destroyed ActivityAndroid API 22 5 seconds after an activity was destroyed, it was still held in memory by a chain of references that originates in SpellCheckerSessionListenerImpl. Here is the leak trace:
SpellCheckerSessionListenerImpl is held in memory for IPC calls. It has a reference to SpellCheckerSession.mHandler. That handler is an anonymous class that therefore has a reference SpellCheckerSession. It's considered a bad practice to create an anonymous Handler class, as noted in the Handler constructor (https://github.com/android/platform_frameworks_base/blob/master/core/java/android/os/Handler.java#L189). That being said, it looks like SpellCheckerSessionListenerImpl.mHandler should get cleared when the session is closed, and here it wasn't. From what I can see, the normal flow is:
So through this path, something wasn't called at some point. This leak was found with LeakCanary: #4 |
Things I would check in the heap dump:
I expect one of these conditions to not hold. |
I'm sorry, can't give you the dump now: every time I try to share a dump, receiver app complains that there is no such file, but it is for another issue. I'll try to reproduce this issue and make a dump tomorrow.
|
The dumps are on the device. If your device is rooted, you can get it with |
There would not be a problem if device were rooted :) Anyway I'll manage to get the dump as soon as I get to my laptop.
|
You can run this command on a debug app if your phone is not rooted |
@andhie wow! That's cool! If only I had known this before I rooted my phone 😔 |
Finally managed to get heapdump, here is a link. |
Condition mPendingTasks looks like following:
|
Cool.
The two pending tasks are TASK_GET_SUGGESTIONS_MULTIPLE_FOR_SENTENCE and TASK_CLOSE. So we're waiting for the service the connect here. When the service connects, it processes the pending tasks. Looks like it never indeed connect, hence creating the leak. |
Is there a hack for this issue? |
It looks like this might have returned in 7.1. Here's a leak we've seen a few times recently:
|
I have following leak on vanilla 5.1 on Nexus 5.
The text was updated successfully, but these errors were encountered: