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) {