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
When shutting down a remote client to HackRF, that connects both as a receiver and transmitter, 4 out of 5 times, the remote server dies from a SEGV in SoapyHackRF::hackrf_rx_callback on the memcpy statement.
I have dig into this and found this is caused by a thread started in the hackrf library continues to call the RX callback routine when the RX stream is closed. It is definitely some kind of race condition, depending on the order in which the threads are deleted. So when the transfer thread started by libhackrf happend so exit first, no problem occurs.
Problem is that SoapyHackRF does not have any handle for that thread.
I have put in a workaround in my code:
if (!_rx_stream.opened) // Workaround to avoid SEGV on client disconnect.
return(0);
right after locking the mutex, which seems to at least avoid the SEGV.
This is probably not the correct solution thogh.
The text was updated successfully, but these errors were encountered:
When shutting down a remote client to HackRF, that connects both as a receiver and transmitter, 4 out of 5 times, the remote server dies from a SEGV in SoapyHackRF::hackrf_rx_callback on the memcpy statement.
I have dig into this and found this is caused by a thread started in the hackrf library continues to call the RX callback routine when the RX stream is closed. It is definitely some kind of race condition, depending on the order in which the threads are deleted. So when the transfer thread started by libhackrf happend so exit first, no problem occurs.
Problem is that SoapyHackRF does not have any handle for that thread.
I have put in a workaround in my code:
right after locking the mutex, which seems to at least avoid the SEGV.
This is probably not the correct solution thogh.
The text was updated successfully, but these errors were encountered: