Segfault bug and solution

[Eric Jesse]

Hey all,

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.

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.

My proposed solution is to change the following condition, "if (r < 0)" to
"if (r < 0 && r != LIBUSB_ERROR_NOT_FOUND)".

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.

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.

Thanks,
Eric Jesse
AMDG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20160329/4769bbff/attachment.htm>