__group__,ticket,summary,type,owner,status,created,_changetime,_description,_reporter libusb-1.0,2,ISO C++ forbids zero-size array 'iso_packet_desc',defect,hjelmn,assigned,2009-07-30T18:06:36+02:00,2013-05-05T19:20:08+02:00,"from: https://sourceforge.net/tracker/?func=detail&aid=2740374&group_id=1674&atid=101674 libusb.h causes errors in C++ projects that use GCC's -pedantic switch: error: ISO C++ forbids zero-size array 'iso_packet_desc' {{{ One solution is to make the array size 1 and account for that change in all places that use sizeof(struct libusb_transfer), e.g.: int alloc_size = sizeof(struct usbi_transfer) + sizeof(struct libusb_transfer) + (sizeof(struct libusb_iso_packet_descriptor) * (iso_packets-1)) + os_alloc_size; }}} {{{ OK. Then I have a possible solution which I don't completely dislike: use an #ifdef to make the array size 1 when using a C++ compiler, but leave the other situations as-is. Outside of the header file, no libusb changes are needed since libusb will always be compiled with a C compiler. What do you think? }}}",dsd libusb-1.0,6,Zero Length Packet issue,defect,,new,2009-08-19T22:58:27+02:00,2013-04-09T05:05:52+02:00,"This patch fixes the Zero Length Packet issue by allowing the client program to specify the LIBUSB_TRANSFER_ZERO_PACKET flag when calling libusb_submit_transfer. This will pass the URB_ZERO_PACKET flag to the appropriate ioctl and thus triggers zero-length packet processing inside the kernel. This patch will also pass the URB_SHORT_NOT_OK flag if LIBUSB_TRANSFER_SHORT_NOT_OK is specified.",nikias libusb-1.0,77,get_max_packet_size returns bad value when alternative interface is used,defect,,new,2010-12-08T16:46:54+01:00,2012-04-19T03:24:34+02:00,"libusb_get_max_packet_size() and libusb_get_max_iso_packet_size() does not consider current alternative interface. I have a device which has endpoint 0x81 in both default interface and alternative interface. When alternative interface is in use, and a call to libusb_get_max_packet_size() takes place, find_endpoint() function stops as soon as it finds the endpoint in the first interface.",eddie.cohen libusb-1.0,123,libusb_handle_events_timeout() only handles one event,defect,hjelmn,assigned,2011-10-05T03:32:18+02:00,2013-05-06T23:04:31+02:00,"It's possible I misunderstand the desired behavior, but: ""If a zero timeval is passed, this function will handle any already-pending events and then immediately return in non-blocking style."" The question is whether it will handle _all_ work that needs to be done at that point. The quote above seems to indicate that it will. However, my observations and also my reading of the code seems to indicate that it basically does _one_ item of work (handles a single event). This makes it somewhat difficult to use in a polling mode application. I call libusb_handle_events_timeout() periodically, hoping to handle everything necessary. However, it seems like it ""falls behind"" in some cases, only handling some events (one event?) each time it's called, and if events arrive at a faster rate than the function is called, then it doesn't work. Furthermore, I can't tell if any events were handled; otherwise, I could just keep looping and calling it until no more events are handled. I can tell whether any of my own callbacks are invoked, but that's not the whole story. For example if I have submitted a transfer with libusb_submit_transfer(), then it appears as if this requires processing in libusb_handle_events_timeout(). (I'm not 100% sure.) I can try to provide a repro case. One way is to call libusb_submit_transfer() a lot to set up a whole pile of pending transfers, then call libusb_handle_events_timeout() -- only some of them (one of them?) actually get queued. So, either: - I am on crack, libusb_handle_events_timeout() with a zero timeout definitely handles ALL pending events (unlike with a nonzero timeout, where it's documented to handle ONE pending event), and I should go soak my head and figure out the problem with my code; - libusb_handle_events_timeout() with a zero timeout indeed only handles ONE pending event (or not all of them, anyway), in which case I think the documentation should be changed and a workaround identified for polling operation. Thx for any help and/or head-soaking you can provide.",egnor libusb-1.0,144,libusb_close() does not block until all submitted transfers have completed,defect,,new,2012-07-27T07:07:40+02:00,2012-07-27T07:07:40+02:00,"Quoting http://marc.info/?m=134331313730019 {{{ The C library does not cancel transfers when libusb_close() is called, and on the other hand libusb_close() does not wait until all transfers have been completed but closes the device immediately - so the transfers will never complete. The application has to clean up all transfers before calling libusb_close(). When using the synchronous API there's no way to cancel a transfer. There are two major alternatives, both of which have been discussed a few times before: 1. Application does not call libusb_close() until after all synchronous transfers have completed 1a. Application uses synchronous API and keeps one internal state to indicate need to wait for all transfers to finish, and only then continue to call libusb_close(). 1b. Application uses asynchronous API and cancels all transfers on exit, and waits until they have all completed. Same internal state is neccessary as in 1a. 2. libusb_close() does not return until all transfers have completed. 2a. libusb_close() simply blocks until all transfers have completed. 2b. libusb_close() first cancels all transfers, and then blocks. 2b. will finish quicker but also requires some internal changes in libusb. 2a. would be simpler to implement. In my opinion the current behavior of libusb_close() could be said to be buggy, and I would like libusb to either do 2a or 2b. There was a bit of discussion, but no patch. }}} ",stuge libusb-1.0,162,libusb_alloc_transfer vulnerable to integer overflow/underflow,defect,,new,2013-02-08T08:56:02+01:00,2013-05-24T20:58:49+02:00,"It's possible to overflow alloc_size in libusb_alloc_transfer by setting iso_packets large enough on 32 bit (iso_packets >= pow(2,32)/12). Once the wrong number of bytes are allocated, it becomes possible to cause invalid memory reads/writes in an executable. libusb_alloc_transfer also accepts a signed integer which is not checked for negative cases, causing os_alloc_size and alloc_size to wrap. Please see the attached patch. It checks for possible overflows/underflows and fails the allocation in advance.",meacer libusb-1.0,17,hotplug/unplug support,enhancement,,new,2009-11-15T14:06:52+01:00,2013-04-11T23:44:54+02:00,"This is a fairly important feature that we're missing. On recent Linux platforms, this is hopefully easy to implement with libgudev.",dsd libusb-1.0,50,Add libusb_reset_endpoint(),enhancement,,new,2010-08-18T16:29:53+02:00,2013-02-09T00:48:56+01:00,See discussion in http://marc.info/?t=128172323000004,stuge libusb-1.0,52,Add libusb_get_framenumber,enhancement,,new,2010-09-19T01:48:23+02:00,2010-09-19T01:48:23+02:00,"See discussion in http://marc.info/?t=128477632000002 It is sometimes useful to get USB frame number. And this is also possible to be implemented without much trouble for Linux, Windows and Mac OS X.",xiaofan libusb-1.0,67,To be able to report the name of the current driver,enhancement,,new,2010-10-09T03:13:10+02:00,2012-04-19T03:47:05+02:00,"Please refer to this thread. http://marc.info/?l=libusb-devel&m=128655552910330&w=2 ""I agree that it makes sense for libusb to be aware of a device's current driver before trying to detach it. It might also be desirable to avoid ever detaching the usbfs driver -- however this is a matter to be settled by the designers and users of libusb. It should not be enforced by the kernel. Certainly libusb-0.1's ability to report the name of the current driver shouldn't be given up in libusb-1.0. That's a backward step. Alan Stern"" ",xiaofan libusb-1.0,107,Basic USB mice example,enhancement,,new,2011-06-13T23:10:04+02:00,2012-04-07T04:17:22+02:00,"Dear all, I am able to write a basic user space driver for USB mice using libusb. I have successfully coded and tested it on linux and windows. I have written python C binding so that python programmers can use it. I have written JNI extensions so that java programmers can use it. I will be very happy to contribute to this website. Or kindly let me place a link to this project on your website. Thanks you very much.... ",weavebytes libusb-1.0,110,[RFC/PATCH/RESEND] Add support to USB3 descriptors,enhancement,,reopened,2011-06-13T23:11:32+02:00,2013-04-22T22:38:46+02:00,"This patch adds support of USB3 descriptors to libusb-1.0: - Add definitions for Endpoint Companion and BOS descriptors. - Add APIs for parsing the Endpoint Companion and BOS descriptors.",merez libusb-1.0,169,darwin/reset_device: handle the case where the device descriptors changed,enhancement,hjelmn,new,2013-04-22T22:18:02+02:00,2013-04-22T22:18:02+02:00,"The Linux kernel causes a device to be reenumeration when reset if the device's descriptors have changed. Darwin does not provide this feature but instead provides a call to force the reenumeration of a device. This behavior is required to support the firmware update protocol used by some devices. Opening a ticket to track this.",hjelmn libusb-1.0,134,Include changes relevant for libusb-1.0.10 from libusbx,task,,new,2012-06-04T12:41:58+02:00,2013-05-22T20:28:52+02:00,,stuge libusb-1.0 Darwin backend,88,Crash during cancellation of transfer when device disconnected,defect,hjelmn,accepted,2011-01-18T05:07:17+01:00,2013-02-08T16:23:32+01:00,"Reproduced this on OSX. Haven't tried yet on Linux. I set up and submit a control transfer, but in the middle I disconnect the device. It crashes (with signal EXC_BAD_ACCESS) on line 1307 (in cancel_control_transfer of darwin_usb.c): {{{ kresult = (*(dpriv->device))->USBDeviceAbortPipeZero (dpriv->device); }}} I think it's a race condition where dpriv->device is made NULL by whatever code detects that the device has disconnected. A simple patch for this particular code path is: {{{ if (!dpriv->device) return LIBUSB_ERROR_NO_DEVICE; kresult = (*(dpriv->device))->USBDeviceAbortPipeZero (dpriv->device); }}} There may be a more generic code path available (& more code paths where this needs to be done).",www.google.com/accounts/o8/id?id=aitoawmz93igogrpknbehv21jdxrf37ft8ksncg libusb-1.0 Darwin backend,152,Darwin: calling libusb_close() from within a transfer completion callback hangs,defect,hjelmn,assigned,2012-09-29T03:52:37+02:00,2013-05-04T19:02:17+02:00,"https://github.com/libusbx/libusbx/issues/38 Not so sure if this is valid or not.",xiaofan libusb-1.0 Darwin backend,165,Darwin: submit_iso_transfer() assumes HS device.,defect,hjelmn,reopened,2013-03-06T23:45:44+01:00,2013-04-23T00:01:57+02:00,"Scheduling multiple isochronous transfers on a FS device fails on OS X. A look into submit_iso_transfer() reveals that it assumes 8 packets per frame when calculating which frame number the following transfer should start at. The attached patch solves this issue for me.",zyp libusb-1.0 Darwin backend,170,Device is no more listed after some number of loop,defect,hjelmn,assigned,2013-04-26T07:50:38+02:00,2013-05-22T20:29:39+02:00,"The attached program will fail during the 21th loop. The device is no more listed by libusb. Edit the source code of the sample and change VENDOR_ID/PRODUCT_ID to your own device. This bug was initialy reported to libusbx at https://github.com/libusbx/libusbx/issues/112",LudovicRousseau libusb-1.0 Darwin backend,171,libusb_get_active_config_descriptor seg faults if device not open,defect,hjelmn,assigned,2013-04-26T07:50:52+02:00,2013-05-05T17:18:09+02:00,"Retrieving the active configuration descriptor using libusb_get_active_config_descriptor on a device that is not open causes a segmentation fault. This is specific to the Darwin backend. It is caused by unchecked dereferencing of priv->device in the function get_configuration_index in os/darwin_usb.c: {{{ static int get_configuration_index (struct libusb_device *dev, int config_value) { struct darwin_device_priv *priv = (struct darwin_device_priv *)dev->os_priv; UInt8 i, numConfig; IOUSBConfigurationDescriptorPtr desc; IOReturn kresult; /* is there a simpler way to determine the index? */ kresult = (*(priv->device))->GetNumberOfConfigurations (priv->device, &numConfig); if (kresult != kIOReturnSuccess) return darwin_to_libusb (kresult); ... }}} The segmentation fault happens when priv->device is used, because for a device that was not opened, its value is NULL. The attached patch fixes this by checking for (priv->device == NULL) and introduces a new error code LIBUSB_ERROR_DEVICE_NOT_OPEN which is returned if this happens. It would of course be nice if one could get the active device descriptor without opening the device, as is possible on other plattforms, but my knowledge of Mac OS X USB and the Darwin backend of libusb is not sufficient to implement this.",afm libusb-1.0 Darwin backend,172,get_active_config_descriptor function returns wrong error when device is not configured,defect,hjelmn,assigned,2013-05-03T13:10:08+02:00,2013-05-03T16:12:17+02:00,"The darwin backend returns LIBUSB_ERROR_INVALID_PARAM in get_active_config_descriptor() when device is not configured. The documentation says it returns LIBUSB_ERROR_NOT_FOUND in this case. The following patch fixes this: {{{ diff --git a/libusb/os/darwin_usb.c b/libusb/os/darwin_usb.c index 3d2c4a6..6313437 100644 --- a/libusb/os/darwin_usb.c +++ b/libusb/os/darwin_usb.c @@ -465,7 +465,7 @@ static int darwin_get_active_config_descriptor(struct libusb int config_index; if (0 == priv->active_config) - return LIBUSB_ERROR_INVALID_PARAM; + return LIBUSB_ERROR_NOT_FOUND; config_index = get_configuration_index (dev, priv->active_config); if (config_index < 0) }}} ",kayahr libusb-1.0 Darwin backend,173,"libusb_get_max_iso_packet_size() with USB3.0, return the USB2.0 value",defect,,new,2013-05-15T21:24:25+02:00,2013-05-22T21:26:08+02:00,"libusb_get_max_iso_packet_size() not consider the libusb_ss_endpoint_companion_descriptor and return the size in the USB2.0 descriptor, for understand in the USB3.0 the isochronous work with burst I propose this patch: {{{ diff --git a/libusb/core.c b/libusb/core.c index 90c4247..7043ee3 100644 --- a/libusb/core.c +++ b/libusb/core.c @@ -864,7 +864,7 @@ int API_EXPORTED libusb_get_max_iso_packet_size(libusb_device *dev, const struct libusb_endpoint_descriptor *ep; enum libusb_transfer_type ep_type; uint16_t val; - int r; + int r,s; r = libusb_get_active_config_descriptor(dev, &config); if (r < 0) { @@ -877,6 +877,20 @@ int API_EXPORTED libusb_get_max_iso_packet_size(libusb_device *dev, if (!ep) return LIBUSB_ERROR_NOT_FOUND; + s = libusb_get_device_speed(dev); + if (s>=4 && ep->extra && ep->extra_length>0) { + // USB3.0 + struct libusb_ss_endpoint_companion_descriptor *ss_ep_companion = NULL; + libusb_parse_ss_endpoint_comp(ep->extra, ep->extra_length, &ss_ep_companion); + if (ss_ep_companion) { + r = ss_ep_companion->wBytesPerInterval; + libusb_free_ss_endpoint_comp(ss_ep_companion); + libusb_free_config_descriptor(config); + return r; + } + } + + // USB1.0, USB2.0 low speed, USB2.0 high speed val = ep->wMaxPacketSize; ep_type = ep->bmAttributes & 0x3; libusb_free_config_descriptor(config); }}} ",manzo libusb-1.0 Linux backend,3,"libusb:error [__open_sysfs_attr], errno=2",defect,,new,2009-07-30T18:11:13+02:00,2012-04-19T03:43:09+02:00,"from https://sourceforge.net/tracker/?func=detail&aid=2104197&group_id=1674&atid=101674 From http://sourceforge.net/mailarchive/message.php?msg_name=20080731112725.5531 0%40gmx.net On linux-2.6.26 a call to libusb_get_device_list gives the following error on the console: libusb:error [__open_sysfs_attr] open /sys/bus/usb/devices/4-1/descriptors failed ret=-1 errno=2 and the functions returns -1. The file ""descriptors"" does not exist in all usb directories. I searched through the directory /sys/bus/usb/devices and found out that a few folder contains the ""descriptors"" file and other not. It seems that the new kernel release doesn't create this file for all devices. I think we have to fall back to usbfs in order to get the descriptor. On linux-2.6.23.1 this error doesn't occur. This is a kernel bug but libusb should be more resilient.",dsd libusb-1.0 Linux backend,131,"Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9",defect,stuge,accepted,2012-06-01T10:24:29+02:00,2013-05-16T20:18:05+02:00,"Some application programs that run with libusb-1.0.8 without problems crash with libusb-1.0.9 ( Segmentation fault )[[BR]] The system is a gentoo linux 64 bit, kernel 3.3.5, gcc 4.5.3 The backtrace shows[[BR]] {{{ Program terminated with signal 11, Segmentation fault. #0 0x00007f23d2014a44 in add_to_flying_list (transfer=0x7f23c4000910) at io.c:1185 1185if (!timerisset(cur_tv) || (cur_tv->tv_sec > timeout->tv_sec) || (gdb) bt #0 0x00007f23d2014a44 in add_to_flying_list (transfer=0x7f23c4000910) at io.c:1185 #1 0x00007f23d2014cc3 in libusb_submit_transfer (transfer=0x7f23c4000968) at io.c:1305 #2 0x00007f23d66853fc in read_thread (param=0x18abd50) at /gnuradiocomponents/gnuradio/gr-fcd/lib/hid/hid-libusb.c:697 #3 0x00007f23d4614f26 in start_thread () from /lib64/libpthread.so.0 #4 0x00007f23d3b37a4d in clone () from /lib64/libc.so.6 (gdb) p cur $1 = (struct usbi_transfer *) 0xfffffffffffffff8 (gdb) p ctx->flying_transfers $2 = {prev = 0x7f23c4000078, next = 0x7f23c4000918} (gdb) p ctx->flying_transfers->next $3 = (struct list_head *) 0x7f23c4000918 (gdb) p ctx->flying_transfers->next->next $4 = (struct list_head *) 0x0 }}} It seems that the end of the list is not recognized in the list_for_each_entry loop. I have no ideas why this happens in 1.0.9 but not in 1.0.8. I possible solution that avoids the crash: Replace {{{ #define list_for_each_entry(pos, head, member, type) for (pos = list_entry((head)->next, type, member);[[BR]] &pos->member!=(head); pos = list_entry(pos->member.next, type, member)) }}} by {{{ #define list_for_each_entry(pos, head, member, type) for (pos = list_entry((head)->next, type, member);[[BR]] (&pos->member!=(head)) &&(pos->member.next != 0 ); pos = list_entry(pos->member.next, type, member)) }}} ",dl1ksv libusb-1.0 Linux backend,133,Smartcard reader not accessible via USB 3.0,defect,,new,2012-06-03T12:52:20+02:00,2013-04-11T15:00:15+02:00,"Hi, I'm using CryptoStick (USB security token with OpenPGP card) with OpenSC (it uses pcsc-lite and this in turn uses libusb). I tried to use the stick on USB 3.0 port but not successful, while USB 2.0 is OK. Attached is the log of libusb 1.0.9. I use under Ubuntu 12.04.",hongquan libusb-1.0 Linux backend,156,Crashing in SUSE when USB device disconnected during write,defect,,new,2012-11-25T00:45:28+01:00,2013-05-07T15:24:28+02:00,"I am having a problem with libussb 1.0.9 on SUSE Enterprise Linux SP2. When I disconnect a USB device while writing to it I get an intermittant crash and as can be seen from the dump below the itransfer structure contains a value of num_iso_packets which is 149879376 which is huge enough that I presume it is corruption. Note that this looks like it might be related to the remaining race condition described at http://libusb.org/ticket/81#comment:14 Comment 15 of that bug then says there might be a solution in 1.0.10, but I do not knwo if that is being actively worked - of course it is not certain that the race condition I am seeing is the same one. {{{ Core was generated by `vxc -t -a 10.53.59.250 -d CSFniamurph2'. Program terminated with signal 11, Segmentation fault. #0 op_clear_transfer_priv (itransfer=0x89f9c38) at os/linux_usbfs.c:1965 1965 os/linux_usbfs.c: No such file or directory. in os/linux_usbfs.c (gdb) bt #0 op_clear_transfer_priv (itransfer=0x89f9c38) at os/linux_usbfs.c:1965 #1 0xaa1941ea in usbi_handle_disconnect (handle=0xa12d18f8) at io.c:2450 #2 0xaa1955de in op_handle_events (ctx=0x8a43920, fds=0xa12d4708, nfds=3, num_ready=0) at os/linux_usbfs.c:2366 #3 0xaa193607 in handle_events (ctx=0x8a43920, tv=0xa84eb014) at io.c:1944 #4 0xaa193e57 in libusb_handle_events_timeout_completed (ctx=0x8a43920, tv=0xa84eb04c, completed=0xa84eb098) at io.c:2024 #5 0xaa193f19 in libusb_handle_events_completed (ctx=0x8a43920, completed=0xa84eb098) at io.c:2123 #6 0xaa194677 in do_sync_bulk_transfer (dev_handle=0xa12d18f8, endpoint=, buffer=0xaa1af7d9 ""\002\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\311""..., length=7129, transferred=0xa84eb0dc, timeout=1000, type=3 '\003') at sync.c:178 #7 0xaa1a7b82 in hid_write () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #8 0xaa1a6a5a in createLCDBody () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #9 0xaa1a45dc in updateLCD () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #10 0xaa1a0d0d in lcdEventUpdate () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #11 0xb42d2879 in start_thread () from /lib/libpthread.so.0 #12 0xb3d17ffe in clone () from /lib/libc.so.6 Backtrace stopped: Not enough registers or memory available to unwind further (gdb) print itransfer $1 = (struct usbi_transfer *) 0x89f9c38 (gdb) print *itransfer $2 = {num_iso_packets = 149879376, list = {prev = 0x8a43970, next = 0x8a43970}, timeout = {tv_sec = 105075, tv_usec = 368421}, transferred = 0, flags = 12 '\f', lock = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = -1, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\000' ""\377, \377\377\377\000\000\000\000\000\000\000"", __align = 0}} (gdb) }}} I modified the code to return from op_clear_transfer_priv in the case where the itransfer was flags=12 (interrupted and device disconnected) to see where I coud get to ( I think that change could have cause memeory leak, but this was an experiment) and it still crashed now with the following: {{{ Program terminated with signal 11, Segmentation fault. #0 0xaa0e0852 in libusb_submit_transfer (transfer=0x89fe03c) at io.c:1290 1290 io.c: No such file or directory. in io.c (gdb) bt #0 0xaa0e0852 in libusb_submit_transfer (transfer=0x89fe03c) at io.c:1290 #1 0xaa0e191f in libusb_control_transfer (dev_handle=0x8d83e58, bmRequestType=33 '!', bRequest=9 '\t', wValue=, wIndex=, data=0xaa0fac00 ""\001\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336\333\336""..., wLength=, timeout=1000) at sync.c:98 #2 0xaa0f4b27 in hid_write () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #3 0xaa0f3a34 in createLCDBody () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #4 0xaa0f15dc in updateLCD () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #5 0xaa0edd0d in lcdEventUpdate () from /opt/cisco/vxc/plugins/libCiscoKeyboardPlugin_4387.so #6 0xb421f879 in start_thread () from /lib/libpthread.so.0 #7 0xb3c64ffe in clone () from /lib/libc.so.6 Backtrace stopped: Not enough registers or memory available to unwind further (gdb) print transfer $1 = (struct libusb_transfer *) 0x89fe03c (gdb) print *transfer $2 = {dev_handle = 0x8d83e58, flags = 2 '\002', endpoint = 0 '\000', type = 0 '\000', timeout = 1000, status = LIBUSB_TRANSFER_COMPLETED, length = 7137, actual_length = 0, callback = 0xaa0e1590 , user_data = 0xa8438098, buffer = 0x89f8b00 ""!\t\001\002"", num_iso_packets = 0, iso_packet_desc = 0x89fe064} (gdb) print *transfer->dv_handle There is no member named dv_handle. (gdb) print *transfer->dev_handle $3 = {lock = {__data = {__lock = 143085064, __count = 33, __owner = -1278254104, __kind = 144697920, __nusers = 144697928, {__spins = 144698128, __list = { __next = 0x89feb10}}}, __size = ""\bN\207\b!\000\000\000\350c\317\263@\352\237\bH\352\237\b\020\353\237\b"", __align = 143085064}, claimed_interfaces = 0, list = {prev = 0x0, next = 0x20}, dev = 0x48, os_priv = 0x8d83e80 """"} (gdb) }}} ",niamurph libusb-1.0 Windows backend,140,Windows backend hangs on XP using multiple threads.,defect,,new,2012-07-09T21:00:09+02:00,2012-09-29T04:09:48+02:00,"I have a program with 2 threads. One thread submits OUT transfers, and another thread calls libusb_handle_events_completed(). This event thread also submits an IN transfer which is re-submitted in it's callback. This code works in Linux, but hangs the program in windows after a short amount of time. I have only tried this in WinXP because that's all I have. Here is a brief section of the debug output: libusb: 1.351944 debug [] handling I/O completion with errcode 0 libusb: 1.361958 debug [] matched endpoint 01 with interface 0 libusb: 1.361958 debug [] could not duplicate handle for CancelIo - using original one libusb: 1.361958 debug [] writing 60 bytes libusb: 1.361958 debug [] add fd 6 events 4 libusb: 1.361958 warning [] Unable to cancel I/O that was started from another thread libusb: 1.361958 debug [] transfer 009D2928 has callback 00464F9F libusb: 1.361958 debug [] no URB with timeout or all handled by OS; no timeout! libusb: 1.361958 debug [] doing our own event handling libusb: 1.361958 debug [] poll() 3 fds with timeout in 60000ms libusb: 1.361958 warning [] invalid fd libusb: 1.361958 debug [] poll() returned -1 libusb: 1.361958 error [] poll failed -1 err=9 And here is a section up to the very end of the log when it hung: libusb: 1.392001 debug [] checking fd 3 with revents = 0000 libusb: 1.392001 debug [] checking fd 4 with revents = 0001 libusb: 1.392001 error [] could not find a matching transfer for fd 4 libusb: 1.392001 error [] backend handle_events failed with error -5 libusb: 1.392001 debug [] no URB with timeout or all handled by OS; no timeout! libusb: 1.402016 debug [] matched endpoint 01 with interface 0 libusb: 1.402016 debug [] could not duplicate handle for CancelIo - using original one libusb: 1.402016 debug [] writing 60 bytes libusb: 1.402016 debug [] add fd 7 events 4 libusb: 1.402016 debug [] doing our own event handling libusb: 1.402016 debug [] poll() 5 fds with timeout in 60000ms libusb: 1.402016 debug [] poll() returned 3 libusb: 1.402016 debug [] checking fd 3 with revents = 0000 libusb: 1.402016 debug [] checking fd 4 with revents = 0001",mozmck libusb-1.0 Windows backend,146,Blue Screen of Death When Stopping Debugger,defect,,new,2012-08-02T10:42:49+02:00,2012-10-17T17:48:24+02:00,"While debugging a project linked against libusb-1.0.9 in Visual C++ 2008, I can fairly regularly get Windows machines to blue screen simply by stopping the debugger (Shift-F5, or Debug->Stop Debugging). I have seen this on Windows XP machines, as well, but I haven't looked into those further. The minidump files left by Windows on Windows 7 64-bit machines claim that the crash occurred in Wdf01000.sys at address: Wdf01000.sys+4c1fb, called from WinUsb.sys at address: WinUsb.sys+137d. I will attach one of these minidump files to this bug report for your perusal, as well.",jleveque libusb-1.0 Windows backend,154,Blue Screen of Death when powering down the device,defect,,new,2012-10-17T17:37:35+02:00,2012-10-17T17:47:35+02:00,"We have build a custom usb device using an Cyprus FX2. This device uses an external power adapter. When disconnecting the power source while trying to retreive data using an bulk endpoint, in about 90% of the cases, we get an bsod in about 2 or 3 seconds. This does not happen on Mac OSX nor Linux and as far as I can tell, only on 64bit windows. I tested using 32 and 64 bit windows 7 installations.",luctius libusb-1.0 Windows backend,157,Max 256 concurrent transfers supported on Windows,defect,,new,2012-12-11T01:49:58+01:00,2012-12-11T01:49:58+01:00,"A fixed size array of per-transfer data structures internal to the Windows backend limits the number of concurrent transfers. See [source:/libusb/libusb/os/poll_windows.h#L48] and [source:/libusb/libusb/os/poll_windows.c#L82] for the details. The original report was by Mohamed HAMZAOUI on libusbx-devel: http://comments.gmane.org/gmane.comp.lib.libusbx.devel/1881",stuge libusb-1.0 Windows backend,49,Support libusb0.sys from libusb-win32 in addition to WinUSB.sys,enhancement,stuge,accepted,2010-08-10T14:50:39+02:00,2013-05-07T15:17:38+02:00,"libusb-win32 device driver (libusb0.sys) has quite some advantages compared to WinUSB. 1) Open source, the device driver is GPLed, with libusb-0.1 compatible library (LGPL). 2) Support multiple configuration USB device. 3) Support isochronous transfer whereas WinUSB does not. 4) Support Windows 2000, Windows 2003 32bit/64bit and Windows XP 64bit, Microsoft does not support WinUSB on these platforms. On the other hand, since version 1.2.0.0, libusb0.sys is digitally signed so it is similar to WinUSB -- both work under 64bit Windows which requires kernel mode driver to be signed, like 64bit Windows Vista or Windows 7. 5) WinUSB does not support multiple concurrent applications.",xiaofan libusb-1.1,127,Interface claiming does not fit OpenBSD's USB stack,defect,,new,2012-02-08T21:54:22+01:00,2012-02-08T21:54:22+01:00,"The OpenBSD backend that relies on the ugen(4) driver to access USB devices doesn't do any useful check in its '''claim_interface()''' and '''release_interface()''' functions. In fact, it's not possible to open the same device more than once at the same time. In other words, there is a lock in the driver and only the first consumer of the API will be able to call '''claim_interface()''' and '''release_interface()''', the others will not be able to open the device.",mpi libusb-1.1,85,Use size_t instead of int in transfer functions,enhancement,,new,2011-01-14T20:18:31+01:00,2013-05-06T16:06:15+02:00,"The POSIX [http://linux.die.net/man/2/read read] and [http://linux.die.net/man/2/write write] functions let you specify the number of bytes to transfer as a [http://en.wikipedia.org/wiki/Size_t size_t]. These functions return a `ssize_t` indicating how much bytes were read or written. (The signed type is needed to allow negative error codes.) As explained in the mailinglist [http://thread.gmane.org/gmane.comp.lib.libusb.devel.general/13712 thread], I would like to propose that the `libusb` transfer functions also use these `size_t` types instead of `int`s. Concretely I propose: {{{ssize_t libusb_control_transfer (...,size_t wLength,...)}}} {{{int libusb_bulk_transfer (...,size_t length, size_t * transferred,...)}}} {{{int libusb_interrupt_transfer (...,size_t length, size_t * transferred,...)}}} Note that the [http://libusb.sourceforge.net/api-1.0/group__dev.html#gac0fe4b65914c5ed036e6cbec61cb0b97 libusb_get_device_list] function already returns a `ssize_t` to indicate the number of devices in the list or an error code. I'm not familiar enough with the asynchronous API but I suppose that it can also use `size_t` types instead of `int`s. ",www.google.com/accounts/o8/id?id=aitoawlbfa_iwnmgtqit6eck5vjmkejlybqinoe libusb-1.1,94,Rename LIBUSB_ENDPOINT_IN and _OUT,enhancement,,new,2011-01-30T15:37:12+01:00,2011-01-30T15:37:12+01:00,"Besides in an endpoint address the constants are applicable at least also in bmRequestType for control transfers. It's a bad idea, and ugly, to have an _ENDPOINT_ constant in the request type field when it has nothing to do with the possibility to set an endpoint as destination for the request.",stuge libusb-1.1,125,libusb_kernel_driver_active() and _detach() are racy,enhancement,,new,2012-02-08T16:40:56+01:00,2013-05-08T17:52:15+02:00,If the functionality is to be kept in the next API then let's do something that isn't racy.,stuge libusb-compat-0.1,141,sispmctl -s crashes on usb startup,defect,,new,2012-07-19T00:22:39+02:00,2012-07-19T00:28:30+02:00,"Sispmctl is using libusb-compat and fails on scanning for available devices. After searching for the source, I think, some error handling is wrong. The program is exiting with the following error: {{{USB set configuration No such file or directory}}} and referes to {{{ioctl(6, USBDEVFS_SETCONFIGURATION, 0x7fffb1f1aafc) = -1 EINVAL (Invalid argument)}}} When looking at the source of sispmctl (current version 3.1) and the attached 'strace sispmctl -s' makes me think, that either {{{usb_init()}}}, {{{usb_find_busses()}}} or {{{usb_find_devices()}}} is buggy. The first position I would search for is the {{{usb_find_busses}}}, because when looking at the strace only /sys/bus/ directories are listed. {{{ usb_init(); usb_find_busses(); usb_find_devices(); for (bus = usb_busses; bus; bus = bus->next) { for (dev = bus->devices; dev; dev = dev->next) { if ((dev->descriptor.idVendor == VENDOR_ID) && ((dev->descriptor.idProduct == PRODUCT_ID_SISPM) || (dev->descriptor.idProduct == PRODUCT_ID_MSISPM_OLD) || (dev->descriptor.idProduct == PRODUCT_ID_MSISPM_FLASH) || (dev->descriptor.idProduct == PRODUCT_ID_SISPM_FLASH_NEW))) { usbdev[count++] = dev; } if (count == MAXGEMBIRD) { fprintf(stderr,""%d devices found. Please recompile if you need to support more devices!\n"",count); break; } } } /* bubble sort them first, thnx Ingo Flaschenberger */ if (count > 1) { do { found = 0; for (i=1; i< count; i++) { if (usbdev[i]->devnum < usbdev[i-1]->devnum) { usbdevtemp = usbdev[i]; usbdev[i] = usbdev[i-1]; usbdev[i-1] = usbdevtemp; found = 1; } } } while (found != 0); } /* get serial number of each device */ for (i=0; i < count; i++) { usb_dev_handle *sudev = NULL; sudev = get_handle(usbdev[i]); if (sudev == NULL) { fprintf(stderr, ""No access to Gembird #%d USB device %s\n"", i, usbdev[i]->filename ); usbdevsn[i] = malloc(5); usbdevsn[i][0] = '#'; usbdevsn[i][1] = '0'+i; usbdevsn[i][2] = '\0'; } else { usbdevsn[i] = strdup(get_serial(sudev)); usb_close(sudev); sudev = NULL; } } }}} My system is running libusb-compat-0.1.4-2 using libusb-1.0.12-2. The Archlinux is up-to-date. {{{ > uname -a Linux rhabarberstrauch 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux }}} When I unplug and replug the gembird device, the problem is gone away. But it reoccurs after short random time. I have attached the output of an 'strace sispmctl -s'. Hopefully you can locate the bug and fix it.",vielleicht libusb-compat-0.1,32,Make libusb-compat-0.1 easier to build for Windows,enhancement,,new,2010-02-20T03:27:06+01:00,2012-05-05T15:56:56+02:00,"Right now it is difficult to build libusb-compat-0.1 under Windows. It would be great to provide the right configure scripts for MinGW/Cygwin and Visual C++ projects files. By doing this, libusb 1.0 Windows backends may appeal to more users and this will help the testing of libusb 1.0 Windows backends (WinUSB and HID currently). Reference thread: http://old.nabble.com/libusb-compat-for-the-libusb-1.0-Windows-backend-td27292398.html",xiaofan