-
-
Notifications
You must be signed in to change notification settings - Fork 172
Panic in NimBLEScan::clearResults() #302
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
Comments
Looks like some sort of timing issue, please try calling scan::stop() before connecting and let me know if that resolves it. |
|
|
It looks like the scan task is being started and receives a result at the same moment you connect task is stopping the scan so the result is colliding with the clearing. Very edge case situation, I'll have to consider options for this. |
I’m only stopping to do a quick client connect. I don’t really want to clear the results. Maybe a , clearResults: false to stop() for this use cas? |
That option is possibly the best. I was considering a mutex or semaphore but i'd prefer not to use those. |
@DTTerastar I've submitted #304 for this, if you would like to test it in your use I would appreciate any feedback. |
I've released a version with it: ESPresense/ESPresense@90cb008 I'll monitor the uptime of the various sensors. |
I'm assuming this is resolved and closing. Please re-open if not. |
Interestingly, I just started encountering this issue with a project of mine which I think relates to the fact that I'm currently performing active scans (ie. I have
The function I'm calling in my loop which is triggering the scan/crash is as follows:
My hypothesis is that having active scanning set can result in the edge case you mentioned. My guess was that the active scan is connecting to devices at the exact same time as I'm trying to clear results, and my solution was to add a After adding this delay I appear to be good - going on 8 hours without a crash (where I was previously seeing one happen every few minutes!) |
The text was updated successfully, but these errors were encountered: