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
Are you seriously not conceding that EFAULT can be caused by trying to write
more bytes than the size of the buffer, instead of a bad pointer? If so, you
should read more kernel code, cause at least in ARM with MMU this is explicitly
checked.
You have also not provided any arguments of why the
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
we don't break here libusbx will
get stuck in
this loop forever. fix #76.
You can merge this Pull Request by running:
git pull https://github.com/miguelfreitas/libusbx issue_76
Or you can view, comment on it, or merge it online at:
https://github.com/libusbx/libusbx/pull/167
-- C
How may I prove you that I'm not providing invalid buffers to libusb?
1) I have already added code to libusb to read and rewrite every byte of the
provided buffer. So if it was a bad pointer case it would certainly have
crashed.
2) The same code runs for days flawless if I just disable the hig
@jwrdegoede I take it back something that i've said in previous comment:
tpriv->usbs is NOT NULL.
The problem is that, no matter if processcompl() succeeds in copying data to
userspace or not, the async was already dequeued, free_async(as) is always
called and so is usb_free_urb(as->urb).
So w
@jwrdegoede let me make an additional argument. even if it were a buggy client
passing invalid pointers to the kernel directly (which is not the case), this
buggy client would still get a nice -EFAULT which he would have a chance to
handle.
But the current behavior of libusbx is not good, imho.
@jwrdegoede I have read the processcompl() you mention and i agree the only
failure case is when one of the put_user or copy_to_user fails. -EFAULT is the
only error code used there.
Another raw guess: is it possible that data was corrupted during USB transfer
(this actually happens here due to
I chose not to use memmove but rather read and write all buffer bytes in a loop
(not sure if memmove would optimize src==dst case). I could successfully
trigger the EFAULT and it did not cause any segfault.
patch (just for reference):
https://gist.github.com/miguelfreitas/8298825
besides i
@jwrdegoede your reasoning sounds good to me. so we are basically concluding it
is either a bug in my client or kernel itself, right?
i have an idea: what if i add a memmove inside libusbx to every
libusb_control_transfer and libusb_bulk_transfer? this way, if i pass an
invalid buffer to libusb
@jwrdegoede you are right about the previous patch being incorrect as you
pointed here:
http://sourceforge.net/mailarchive/message.php?msg_id=31068411
I have just tried exiting the while when libusb_cancel_transfer() != 0. As you
predicted, we can't use libusb_free_transfer() because it will ca
@jwrdegoede here is what happens with current master:
```
libusbx: error [reap_for_handle] reap failed error -1 errno=14
libusbx: error [handle_events] backend handle_events failed with error -1
libusbx: error [sync_transfer_wait_for_completion] libusb_handle_events failed:
LIBUSB_ERROR_IO, cance
ok, let's admit the theory of flipping random RAM bits. so why would it just
flip the bits of the buffer used for usb transfers instead of crashing my
program? i had seen memory problems before and i tell you they are not
deterministic like that.
another question: can you completely rule out th
Hi Hans, I about to dive into this issue. I have not yet read libusbx code but
I can basically assure you this errno=14 can be caused by USB transfer errors.
Here is the evidence:
We develop a USB-based ultrasound hardware here at the university and the USB
transfer errors are our long time fri
14 matches
Mail list logo
