-
Notifications
You must be signed in to change notification settings - Fork 199
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
Plugin leaks receivers upon connection attempts #528
Comments
@dariuszseweryn the stacktrace from AndroidStudio seems to point directly at the place in question.. |
Hi @b055man |
@dariuszseweryn main.dart
connect_ble.dart
Press 'start connecting' and wait a bit. You'll get:
|
If you could create a repository which I could clone, build and recreate the issue — that would be perfect |
@dariuszseweryn Ok, here you go: https://github.com/b055man/ble_lib_leak |
@dariuszseweryn were you able to reproduce the issue maybe? |
@mikolak @dariuszseweryn Can I be of any help with addressing this issue? Thanks, |
Hello @b055man |
I'm not sure if LeakCanary is good in tracing leaked Broadcast receivers.. Anyway, I can see a leak warning (pointing to RxBleAdapterStateObservable) if I do even a single connection attempt and trigger the heap dump (simply by leaving the app/putting it in the background). What's also interesting is that if I destroy the BLE client after all connection attempts, there are no leak warnings, yet the receivers are still leaked - the app will crash upon hitting the 1000th connection attempt. Here's the output from LeakCanary - I hope it can be helpful.
|
@dariuszseweryn @mikolak I run a similar test using the Flutter Reactive Ble package (https://pub.dev/packages/flutter_reactive_ble), which uses Polidea's rxandroidble library too (it interacts with it directly, not via the MultiplatformBleAdapter) - the difference is that they use the most-up-to-date version of the rxandroidble library, whereas the MultiAdapter still uses a 2-years old version (1.7.1). The RxStateObservable leak was fixed in version 1.10.0 dariuszseweryn/RxAndroidBle#575 |
@dariuszseweryn another updated: as expected, using a newer version of the rxandroidble library solves this issue... but it's not that easy to migrate, as it now uses RxJava2. So, guys @dariuszseweryn @mikolak - any chance to pursue that James's PR and moving MultiPlatformBleAdapter to RxJava2, to allow using recent versions of the rxandroidble library? |
@mikolak @dariuszseweryn Guys, can you comment, please? |
Hi! Sorry for the long silence, I'm completely swamped with work right now. I'd love to migrate it to new RxAndroidBLE, but I seem to recall there might be some issue with global error listeners (?). I hope to have some time from November. I'll consult it internally and try to get back to you, though I can't promise timely manner right now. Thank you for investigating it so thoroughly! |
@mikolak Thanks for providing the rough timeframe - I will bump the topic again sometime in Nov then, unless there are some updates before that time. |
@mikolak @dariuszseweryn Hi guys, any updates on this one? |
@b055man I've just released 3.0.0-beta (https://github.com/Polidea/FlutterBleLib/releases/tag/v3.0.0-beta) with RxAndroidBle 2. Give it a go, lemme know if you encounter any issues. Let me know if everything works fine as well, as this will have to leave beta some day. Closing for now. |
@mikolak Thanks. We'll give it a spin and I'll let you know the results. |
@PiotrJozefow I had a look last week and found a source of leaking, it's RxJava subscriptions in the MultiPlatformBleAdapter, will look at at PR when I get a moment. |
@JamesMcIntosh I have no idea why but the memory leak I have occurs only when I have flutter animationController running on repeat at the time of peripherial scan. Thanks for fixing this and I'm really looking forward to your PR being merged 💪 |
@PiotrJozefow are you repeatedly calling |
@bo55man @JamesMcIntosh have you encountered any issues using the beta? |
@mikolak I haven't had a chance to get back to it yet but I'm pretty sure it was affected by the same problem because of the way RxJava2 is used with subscriptions / observales. |
Observed on version: 2.2.9
After leaving the application reconnecting to a gone device for several hours, the app is no longer operational - it is not possible to register any receivers as app hit the limit of 1000 registered ones.
When it happened once, I later tried to pinpoint the culprit (wasnt't sure if this may be scanning related, or maybe even Wifi portion of the app's functionality) and I reproduced it quickly by repeatedly initiating connections.
Snippet from the code handling the connection:
Once 1000 connections were reached, this is what I got:
With a profiler from Android Studio I am indeed able to see that there are things that are not released and clearly point to flutter_ble_lib - or rather rxandroidble
Once that exception is hit, subsequent calls to connect method end instantly with the following error:
There doesn't seem to be a way of recovering from this - destroying the client does not help. Only way to resolve that seems to require swiping out the app from the recents application list.
I noticed an issue about a leak in the rxandroidble but it was related to scanning (dariuszseweryn/RxAndroidBle#607) - this one seems to be a bigger issue.
Any hints are appreciated - this is a huge deal for the app I'm working on.
The text was updated successfully, but these errors were encountered: