-
Notifications
You must be signed in to change notification settings - Fork 304
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
Program disconnects before connection established. Locks up Bleak #535
Labels
Backend: Core Bluetooth
Issues and PRs relating to the Core Bluetooth backend
bug
Something isn't working
Comments
dlech
added
Backend: Core Bluetooth
Issues and PRs relating to the Core Bluetooth backend
bug
Something isn't working
labels
May 12, 2021
Thanks for reporting the issue. It looks like we need to at least add a timeout while waiting for services to be enumerated. Even better would be to allow it to be interrupted by the disconnect event. |
Are there any updates on this? is there anything i can do to help with this? |
dlech
added a commit
to dlech/bleak
that referenced
this issue
Jun 3, 2021
This fixes hbldh#535. In the CoreBluetooth backend, when a device disconnects, none of the peripheral delegate callbacks will be called. So if any futures are pending, they will be waiting forever. This adds a disconnect hook that will raise an exception in all pending futures to avoid this deadlock.
dlech
added a commit
to dlech/bleak
that referenced
this issue
Jun 3, 2021
This fixes hbldh#535. In the CoreBluetooth backend, when a device disconnects, none of the peripheral delegate callbacks will be called. So if any futures are pending, they will be waiting forever. This adds a disconnect hook that will raise an exception in all pending futures to avoid this deadlock.
Hi @Dallin-Lloyd, can you please test #557? |
dlech
added a commit
to dlech/bleak
that referenced
this issue
Jun 5, 2021
This fixes hbldh#535. In the CoreBluetooth backend, when a device disconnects, none of the peripheral delegate callbacks will be called. So if any futures are pending, they will be waiting forever. This adds a disconnect hook that will raise an exception in all pending futures to avoid this deadlock.
dlech
added a commit
to dlech/bleak
that referenced
this issue
Jun 5, 2021
This fixes hbldh#535. In the CoreBluetooth backend, when a device disconnects, none of the peripheral delegate callbacks will be called. So if any futures are pending, they will be waiting forever. This adds a disconnect hook that will raise an exception in all pending futures to avoid this deadlock.
Merged
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Backend: Core Bluetooth
Issues and PRs relating to the Core Bluetooth backend
bug
Something isn't working
bluetoothctl -v
) in case of Linux:Description
Describe what you were trying to get done.
Trying to connect and disconnect from an array of devices. trying to connect and then disconnect to make sure devices under test are working properly. I am iterating through the devices and cycling the connect/disconnect N number of times.
(devices have firmware that sends device to sleep. sometimes wont wake up)
Tell us what happened, what went wrong, and what you expected to happen.
Program would freeze after 20-30 connect / disconnect cycles.
What I Did
i added print statements to client.py and scanner.py to monitor in the terminal where it was freezing.
This was to help me visualize. It appears that sometimes the disconnect callback gets called and locks up the program. its call back to disconnect before it has established a connection.
It is preferable if an issue contains a Miminal Workable Example.
This will otherwise be one of the first questions you will get as a response.
It is also preferable if that example is not dependent on a specific peripheral device, but can be run and
reproduced with other BLE peripherals as well.
my output normally looks like this:
When the program freezes, it looks like this:
The text was updated successfully, but these errors were encountered: