Chrome doesn't shutdown because of libusb |
|||||||||
Issue descriptionIf I open Chrome on Windows and then close it, it never shuts down. Worse, the process is unkillable because it's in a kernel call. This is the callstack (on the FILE thread): ntdll.dll!_ZwDeviceIoControlFile@40 () Unknown KernelBase.dll!_DeviceIoControl@32 () Unknown kernel32.dll!_DeviceIoControlImplementation@32 () Unknown chrome.dll!init_device(libusb_device * dev, libusb_device * parent_dev, unsigned char port_number, char * device_id, unsigned long devinst) Line 1141 C chrome.dll!windows_get_device_list(libusb_context * ctx, discovered_devs * * _discdevs) Line 1633 C > chrome.dll!libusb_get_device_list(libusb_context * ctx, libusb_device * * * list) Line 683 C chrome.dll!device::`anonymous namespace'::GetDeviceListOnBlockingThread(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & new_device_path, scoped_refptr<device::UsbContext> usb_context, scoped_refptr<base::SequencedTaskRunner> task_runner, base::Callback<void __cdecl(libusb_device * *,unsigned int),1,1> callback) Line 101 C++ . . .
,
Oct 15 2016
Not technically a WebUSB issue. The existing chrome.usb API code could have triggered this but since enabling WebUSB means that this code is now initializing on every browser start (instead of just for users with USB-using Chrome Apps) we're going to see more bugs like this. Is this reproducible or a one-off issue? In this case we're executing IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX. DeviceIoControl() doesn't have a timeout parameter and I don't know if calling IOCTL_SET_TIMEOUT first will effect this call since this isn't clearly a USB transfer. You wouldn't happen to have saved a full system minidump from this? Then I could take a look at what the kernel is up to and hopefully figured out why it got stuck.
,
Oct 15 2016
,
Oct 18 2016
Followup fix for issue : 656702 . Please feel free to update the labels if needed.
,
Oct 26 2016
Gentle Ping! Since this issue marked as RB stable can we get any update on this issue?
,
Oct 26 2016
**** Bulk edit - please ignore if not applicable **** A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!
,
Oct 26 2016
I don't believe this is a release blocking issue after the mitigation put in place in issue 656702 . A proper fix is a larger project that can only reasonably be completed in the M-56 timeframe.
,
Mar 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/76a2fa3cf40ee87f63d123c131b5ef5f15cdd7a6 commit 76a2fa3cf40ee87f63d123c131b5ef5f15cdd7a6 Author: reillyg <reillyg@chromium.org> Date: Tue Mar 07 18:47:43 2017 Enable WebUSB device detection when using the new Windows USB backend. One of the goals of the new USB backend on Windows is to resolve the issue of Chrome getting stuck in blocking USB ioctls inside libusb so let's re-enable WebUSB device detection when running with the new backend enabled (which is so far disabled by default). BUG= 652416 Review-Url: https://codereview.chromium.org/2734933003 Cr-Commit-Position: refs/heads/master@{#455157} [modify] https://crrev.com/76a2fa3cf40ee87f63d123c131b5ef5f15cdd7a6/chrome/browser/usb/web_usb_detector.cc
,
Mar 29 2017
,
Apr 20 2017
This isn't a Pri 1, see comment 7. It's even borderline for Pri 2.
,
May 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/402c8ae126b3f215c11c3845637542db2a68ccc5 commit 402c8ae126b3f215c11c3845637542db2a68ccc5 Author: reillyg <reillyg@chromium.org> Date: Wed May 03 14:45:02 2017 Use the task scheduler in the USB service on macOS and Windows This updates the libusb-based USB service to use the task scheduler which means it will be enabled on macOS and Windows. The new Windows USB service will be updated next. By executing these tasks on a sequence with the CONTINUE_ON_SHUTDOWN trait a device or driver bug that causes a request to lock up should not prevent Chrome from shutting down. BUG= 652416 ,703585 Review-Url: https://codereview.chromium.org/2857473002 Cr-Commit-Position: refs/heads/master@{#468967} [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_device_handle_impl.cc [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_device_impl.cc [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_device_impl.h [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_service.cc [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_service_impl.cc [modify] https://crrev.com/402c8ae126b3f215c11c3845637542db2a68ccc5/device/usb/usb_service_impl.h
,
May 3 2017
Even in the face of driver/device bugs USB should now no longer be shutdown blocking. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by scheib@chromium.org
, Oct 15 2016