Package: libusb
Version: 2:0.1.12-2
Severity: normal
Tags: patch
Libusb calls select() in a loop, but does not re-initialize the fd_set.
So every call after the first one is just a delay. This doesn't make
any difference in practice since the timeout is always 1ms, but I noticed
it while debugging another problem in our application, so here's a patch.
The symptom is, when stracing something that takes more than 1ms to respond,
you'll see a lot of calls to select where writefds is [] instead of e.g.
[3].
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-rc3
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
---
linux.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: libusb-0.1.12/linux.c
===================================================================
--- libusb-0.1.12.orig/linux.c 2007-01-12 10:02:24.000000000 -0500
+++ libusb-0.1.12/linux.c 2007-01-12 10:02:37.000000000 -0500
@@ -213,15 +213,14 @@ static int usb_urb_transfer(usb_dev_hand
return ret;
}
- FD_ZERO(&writefds);
- FD_SET(dev->fd, &writefds);
-
restart:
waiting = 1;
context = NULL;
while (!urb.usercontext && ((ret = ioctl(dev->fd, IOCTL_USB_REAPURBNDELAY, &context)) == -1) && waiting) {
tv.tv_sec = 0;
tv.tv_usec = 1000; // 1 msec
+ FD_ZERO(&writefds);
+ FD_SET(dev->fd, &writefds);
select(dev->fd + 1, NULL, &writefds, NULL, &tv); //sub second wait
if (timeout) {
