-
-
Notifications
You must be signed in to change notification settings - Fork 481
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 Canary report #114
Comments
@ryanheise |
A memory leak is only of concern in this case if new memory is being allocated each time the app is re-entered without de-allocating the old memory because otherwise the app is only allocating constant memory which the O/S can reclaim whenever it's running low on memory. So even if audio_service retains memory after Activity.onDestroy, that would not necessarily cause the very high memory usage. To determine that, you would need to provide more information. What was the memory usage on the first run of the app, and the second, and the third, and so on? If each time you back out and re-enter the app the memory usage grows, then that is of concern. I am doubtful that a leak is causing memory usage to grow because the references that I do retain are not stored in a growing list, sot the memory usage should stay roughly constant(*), and can be cleared as needed by the O/S. (*) At most, there will be two instances of the plugin, and each instance should have constant memory usage. |
Each time I back out of the app and re-enter the app the memory usage keeps growing. ├─ com.ryanheise.audioservice.AudioServicePlugin$ClientHandler This issue is very important because the leak occurs without even starting your audioservice. My understanding of the report is that ClientHandler class is leaking. |
The memory usage growth that I monitored was as follows:
I manually also ran GC using the dev tools. GC was also unable to purge all the memory. Finally the maximum usage reached a whopping 2.7 GB when viewed on android device, which was very alarming. |
I agree this is alarming. I'll investigate today. |
@rohansohonee I was unable to reproduce the runaway memory problem. On my phone (Pixel 3a), the memory remained constant after repeatedly backing out and re-entering the app. However I addressed the memory leaks reported by LeakCanary, so please let me know if it solves the issue for you. |
Ok Will be checking now |
METADATA
|
Now it seems the leak is coming from TTS plugin |
Since that's a separate plugin, would you say the issue with audio_service is resolved? |
Yes |
Great, good to know and thanks for reporting. |
Hi @ryanheise Can we reopen this issue. The latest commit
Do have a look at this. |
If this is related to the new v2 implementation I just committed, I've still left that issue open so it would be best to post all issues related to that commit in that issue (i.e. #145). |
@ryanheise
|
Thanks, I have fixed it in the latest commit (aside from the leak that comes from the |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service. |
Describe the bug
The application is leaking memory when opening and closing the application.
Minimal reproduction project
Example project produces this report.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No memory leaks should be present in the application.
Leak Canary Report
ApplicationLeak(className=com.ryanheise.audioserviceexample.MainActivity, leakTrace=
┬
├─ android.os.HandlerThread
│ Leaking: NO (PathClassLoader↓ is not leaking)
│ Thread name: 'LeakCanary-Heap-Dump'
│ GC Root: Thread object
│ ↓ thread HandlerThread.contextClassLoader
├─ dalvik.system.PathClassLoader
│ Leaking: NO (Object[]↓ is not leaking and A ClassLoader is never leaking)
│ ↓ PathClassLoader.runtimeInternalObjects
├─ java.lang.Object[]
│ Leaking: NO (AudioServicePlugin↓ is not leaking)
│ ↓ array Object[].[512]
├─ com.ryanheise.audioservice.AudioServicePlugin
│ Leaking: NO (a class is never leaking)
│ ↓ static AudioServicePlugin.clientHandler
│ ~~~~~~~~~~~~~
├─ com.ryanheise.audioservice.AudioServicePlugin$ClientHandler
│ Leaking: UNKNOWN
│ ↓ AudioServicePlugin$ClientHandler.connectionCallback
│ ~~~~~~~~~~~~~~~~~~
├─ com.ryanheise.audioservice.AudioServicePlugin$ClientHandler$3
│ Leaking: UNKNOWN
│ Anonymous subclass of android.support.v4.media.MediaBrowserCompat$ConnectionCallback
│ ↓ AudioServicePlugin$ClientHandler$3.mConnectionCallbackInternal
│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
├─ android.support.v4.media.MediaBrowserCompat$MediaBrowserImplApi26
│ Leaking: UNKNOWN
│ ↓ MediaBrowserCompat$MediaBrowserImplApi26.mContext
│ ~~~~~~~~
╰→ com.ryanheise.audioserviceexample.MainActivity
Leaking: YES (Activity#mDestroyed is true and ObjectWatcher was watching this)
key = 67498789-00a3-42fe-b139-6eaddb476355
watchDurationMillis = 5135
retainedDurationMillis = 133
, retainedHeapByteSize=22818)
Runtime Environment:
Flutter SDK version
Additional Context
Leak Canary getting started
The text was updated successfully, but these errors were encountered: