Here we are almost a year later, and the "not-found" error return from
libusb_cancel_transfer is not being handled. It appears efforts here were
stopped because one person can cause this problem in a manner that also
involves EFAULTs. In the end, however, there's still a looping bug in libusb,
As complete outside to this thread observing from the far:
I don't understand Hans approach here.
I looks to me that here we have Miguel with a reproducible case where a
an infinite loop inside libusb can be triggered by disturbing the USB
communication externally without touching the code in an
I already explained what causes the EFAULT, and it is not bad pointer, but you
don't want to hear. so sorry.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/167#issuecomment-32019265
Closed #167.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/167--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLi
as discussed to dead in issue #76 the problem you're seeing and trying
to fix is caused by a bad pointer *somewhere* as the EFAULT clearly indicated.
Strong NACK from me. For the last time stop trying to propagate the EFAULT, do
your homework and debug the cause of the EFAULT and fix that, than
Hi Pete, for me it is fairly easy to reproduce with an ultrasound equipment we
developed in PUC-Rio university using Opalkelly FPGA cards (which include USB
ports). I can run our app + libusbx receiving tons of data for days flawless if
the highvoltage ultrasound power supply is disabled.
Howe
Thanks for the patch. We'll see what we can do to integrate it, but can you
tell us a bit more about the circumstances where this behaviour occurs, and how
easy or difficult it is to produce (i.e. do you see the infinite loop
consistently happening in an app, or is it a bit more random)?
/Pete
exit from sync_transfer_wait_for_completion when libusb_handle_events_completed
failed
and libusb_cancel_transfer returns LIBUSB_ERROR_NOT_FOUND. this error is
returned when
urbs is not found in kernel (it was already dequeued from async_completed list),
therefore there is nothing to cancel. if w
