-
Notifications
You must be signed in to change notification settings - Fork 490
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
Bluepy_helper 100% CPU infinite loop on failed write with response #332
Comments
Any updates on this one. Seeing same behaviour with Home assistant and rpi 4 |
Same issue here. Any update? |
Same here - any idea how to solve it? Thanks! |
fsaris
added a commit
to fsaris/bluepy
that referenced
this issue
Apr 29, 2021
After the BLE Connection is established, a L2CAP socket will be added the GLib Poll list via "g_io_add_watch()". But unfortunately the "G_IO_NVAL" is missing in the Condition Parameter of the "g_io_add_watch()". Therefore if Disconnection happens (no matter it's triggered by the BluePy side, or another side), namely the L2CAP Socket is closed by the Kernel Bluetooth Subsystem . The missing condition "G_IO_NVAL" causes that the cleanup callback "channel_watcher" will not be called. In this case, the GIO Event Source will not be removed from the GLib Poll list properly. And the following infinite Loop happens and raises CPU Usage to 100%. poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=0}], 3, -1) = 2 ([{fd=4, revents=POLLIN}, {fd=5, revents=POLLNVAL}]) // cleanup should happen, but not poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=0}], 3, -1) = 1 ([{fd=5, revents=POLLNVAL}]) poll([{fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=0}], 3, -1) = 1 ([{fd=5, revents=POLLNVAL}])
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using: bluepy 1.2.0 on ubuntu 18.04 with a UD100 in docker.
Problem: I discovered that when no response is returned from a write withResponse=True call on a characteristic,
btmon
shows that the connection is eventually closed, butbluepy_helper
keeps callingpoll
with a closed file descriptor at 100% CPU, seemingly in an infinite loop.Solution: The helper process has to be killed manually (or via a watcher daemon)
I think this is a bug in
bluepy_helper
- if the connection is closed on a failed write with response, the helper should exit and an error should be returned to the bluepy code, rather than seemingly retrying forever.Originally posted by @DylanSale in #239 (comment)
The text was updated successfully, but these errors were encountered: