<div dir="ltr">Hey all,<br><br>I've been looking into a seg fault bug appearing after asynchronous reads, and I wanted to put forward my thoughts, and a potential solution, perhaps for the official release.<br><br>I looked into the C source code and
 have ultimately determined that problem lies in the rtlsdr_read_async function in 
librtlsdr.c, which usually (if not always) returns a -5. I've traced 
this error back to the libusb_cancel_transfer function.<br><br>My 
proposed solution is to change the following condition, "if (r < 0)" 
to "if (r < 0 && r != LIBUSB_ERROR_NOT_FOUND)". <br><br>Why? It's been noted that the new transfer status from the 
libusb_cancel_transfer function does not propagate immediately (and to 
be honest, I'm not sure when exactly it propagates). As it is now, if the 
function returns successfully (r=0), the function runs through the while
 loop again, and checks all the functions to see if they are cancelled. 
If not, (i.e. the status hasn't propagated) the libusb_cancel_transfer 
function is called again, but this time it returns 
LIBUSB_ERROR_NOT_FOUND, which according to the function description in the libusb documentation 
means "the transfer is not in progress, already complete, or already 
cancelled" and is treated as an error. This does not sound to me like an
 error, but something that can be ignored to give time for the already 
"cancelled" signal to obtain the "CANCELED" status.<br><br>I've 
implemented the change personally, and everything seems to work fine. I 
don't know if others have seen the same seg fault problem I have, but this seems to be a working, minimal solution. Let me know if I'm interpreting the "transfer is not in progress, 
already complete, or already cancelled" wrong, since I don't want to ignore any 
actual problems.<br><br>Thanks,<br>Eric Jesse<br>AMDG<br></div>