{5} Accepted, Active Tickets by Owner (Full Description) (3 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
hjelmn (1 match)
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #88 | Crash during cancellation of transfer when device disconnected | libusb-1.0 Darwin backend | libusb/libusbx 1.2.0 | defect | 01/18/11 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
stuge (2 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #131 | Some application programs ( gqrx, gnuradio ) crash with libusb-1.0.9 | libusb-1.0 Linux backend | 1.0.10 | defect | 06/01/12 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some application programs that run with libusb-1.0.8 without problems crash with libusb-1.0.9 ( Segmentation fault ) 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))
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #49 | Support libusb0.sys from libusb-win32 in addition to WinUSB.sys | libusb-1.0 Windows backend | 1.0.17 | enhancement | 08/10/10 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||