You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running with gdb shows that the hang happens when hackrf_stop_rx() calls cancel_transfers(), which calls pthread_cond_wait to wait for cancellations to complete. But the transfer thread is already dead, because hackrf_libusb_transfer_callback saw an error and called request_exit. So the condition is never set.
We need to rethink the error handling path to work with the other changes. I'll work on that.
The text was updated successfully, but these errors were encountered:
Steps to reproduce
hackrf_transfer -r /dev/null
Expected behaviour
Program exits with an appropriate error.
Actual behaviour
Program hangs, and can only be killed with
SIGKILL
.Background
I decided to test this after writing this comment, because disconnection was the obvious case for when we would need to handle errors from libusb.
It looks like I broke this in #1029.
Running with gdb shows that the hang happens when
hackrf_stop_rx()
callscancel_transfers()
, which callspthread_cond_wait
to wait for cancellations to complete. But the transfer thread is already dead, becausehackrf_libusb_transfer_callback
saw an error and calledrequest_exit
. So the condition is never set.We need to rethink the error handling path to work with the other changes. I'll work on that.
The text was updated successfully, but these errors were encountered: