Crash during cancellation of transfer when device disconnected

[www.google.com/accounts/o8/id?id=aitoawmz93igogrpknbehv21jdxrf37ft8ksncg]

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]

The suggested check of dpriv->device before dereferencing it does not completely eliminate the race condition, although it makes the race window much smaller.

Hopefully Nathan can have a look at this and find a good solution. (Does dpriv need a lock for ->device?)

[hjelmn]

I will look into this problem and see if there is a way to completely eliminate the race condition.

[www.google.com/accounts/o8/id?id=aitoawkqduuilezm1tu1seo2uz1ndphzkn82lqc]

Check out the patch set for ticket #82. It might fix this problem.

[hjelmn]

Adding a check on dpriv->device is a good idea. Approved for 1.0.9.

[Vitali Lovich <vlovich@…>]

In [0c5bf03eb829e51dcf19562fc4f745937235ea51/libusb]:

Darwin: Reduce race likelihood between cancellation and device disconnect

References #88. The race condition still remains, but this change
makes it less likely to trigger.