From: Richard B. <ra...@lu...> - 2014-12-10 18:34:28
|
> > > No, you have received no "consensus" of any kind. You're going to need > to figure out what combination of things triggers this. Are the calls > to libusb_get_device_list in a separate thread? Does this happen only > when you call libusb_get_device_list while one of your reads is > outstanding? If this is caused by some interference between the two > processes, that's a problem that can be tackled, but it's going to take > some analysis. > > As it is, you have nothing but vague suspicions. > > I know I haven't received a "consensus", that's why I was asking... The program interacts with libusb within a single thread. Calls to libusb_get_device_list never occur when a bulk transfer read or write is occurring. As it was I had no suspicions at all as to the cause of the problem, I was just repeating what Xiaofan had said the cause of the problem might be. Some less-vagues supsicions though... Based on the absence of certain error/warning messages in the debug log, I believe the error is triggered at calls to one of the following places: https://github.com/libusb/libusb/blob/ada59db186aa95215158129db8cd42e079daff07/libusb/os/windows_usb.c#L118 https://github.com/libusb/libusb/blob/ada59db186aa95215158129db8cd42e079daff07/libusb/os/windows_usb.c#L123 https://github.com/libusb/libusb/blob/ada59db186aa95215158129db8cd42e079daff07/libusb/os/windows_usb.c#L1412 The debug message associated with the last place (line 1412) happens regularly -- before any errors with devices occur. Additionally, the devices with which the problem occurs are not HID devices. So its probably coming from CHECK_WINUSBX_AVAILABLE? But I wouldn't expect the sub_api to somehow become uninitialized after being initialized correctly at the start... And there are no errors in the log that would indicate this. I'll see if I can make a simple test program that reproduces this consistently. |