IOHIDDeviceCreate should not be called on the UI thread |
||
Issue descriptionChrome Version: 58.0.3029.14 (Official Build) dev (64-bit) OS: macOS 10_12_3 I'm using an experimental HID device connected to a Chrome extension, and it has some reliability issues. But this is affecting Chrome's UI by causing it to hang repeatedly whenever the extension tries to connect to the device. This is because extensions::HidConnectFunction::Run() is called on the UI thread, which in turn calls device::HidServiceMac::Connect() and that calls IOHIDDeviceCreate. That can result in a synchronous wait to communicate with hardware. The entirety of device::HidServiceMac::Connect needs to be called on the blocking pool. 283 Thread_3947503 DispatchQueue_1: com.apple.main-thread (serial) + 283 start (in libdyld.dylib) + 1 [0x7fffa76a3255] + 283 main (in Google Chrome) + 522 [chrome_exe_main_mac.c:89] + 283 ChromeMain (in Google Chrome Framework) + 111 [chrome_main.cc:0] + 283 content::ContentMain(content::ContentMainParams const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x1596ac6 [content_main.cc:20] + 283 content::ContentMainRunnerImpl::Run() (in Google Chrome Framework) load address 0x114b3c000 + 0x15977b0 [content_main_runner.cc:836] + 283 content::BrowserMain(content::MainFunctionParams const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x4ad58c [browser_main.cc:46] + 283 content::BrowserMainRunnerImpl::Run() (in Google Chrome Framework) load address 0x114b3c000 + 0x4b4932 [memory:2586] + 283 content::BrowserMainLoop::RunMainMessageLoopParts() (in Google Chrome Framework) load address 0x114b3c000 + 0x4b1984 [browser_main_loop.cc:1185] + 283 ChromeBrowserMainParts::MainMessageLoopRun(int*) (in Google Chrome Framework) load address 0x114b3c000 + 0x15def49 [chrome_browser_main.cc:2003] + 283 base::RunLoop::Run() (in Google Chrome Framework) load address 0x114b3c000 + 0x1a5aa33 [run_loop.cc:38] + 283 base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a3c45c [message_pump_mac.mm:300] + 283 base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a3ce3e [message_pump_mac.mm:772] + 283 -[NSApplication run] (in AppKit) + 926 [0x7fff8fbcbf35] + 283 -[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in Google Chrome Framework) load address 0x114b3c000 + 0x15d93b9 [chrome_browser_application_mac.mm:192] + 283 base::mac::CallWithEHFrame(void () block_pointer) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a2cefa [] + 283 __71-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke (in Google Chrome Framework) load address 0x114b3c000 + 0x15d9480 [chrome_browser_application_mac.mm:187] + 283 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit) + 2789 [0x7fff90351d6b] + 283 _DPSNextEvent (in AppKit) + 1120 [0x7fff8fbd75b4] + 283 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 71 [0x7fff916316c6] + 283 ReceiveNextEventCommon (in HIToolbox) + 432 [0x7fff91631891] + 283 RunCurrentEventLoopInMode (in HIToolbox) + 240 [0x7fff91631a5c] + 283 CFRunLoopRunSpecific (in CoreFoundation) + 420 [0x7fff920a6b54] + 283 __CFRunLoopRun (in CoreFoundation) + 934 [0x7fff920a7156] + 283 __CFRunLoopDoSources0 (in CoreFoundation) + 556 [0x7fff920a7c6c] + 283 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) + 17 [0x7fff920c68d1] + 283 base::MessagePumpCFRunLoopBase::RunWorkSource(void*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a3c024 [message_pump_mac.mm:399] + 283 base::mac::CallWithEHFrame(void () block_pointer) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a2cefa [] + 283 base::MessagePumpCFRunLoopBase::RunWork() (in Google Chrome Framework) load address 0x114b3c000 + 0x1a3c5fa [message_pump_mac.mm:420] + 283 base::MessageLoop::DoWork() (in Google Chrome Framework) load address 0x114b3c000 + 0x1a391e3 [message_loop.cc:527] + 283 base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a38e1c [message_loop.cc:434] + 283 base::MessageLoop::RunTask(base::PendingTask*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a38acb [vector:638] + 283 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1a13010 [callback_forward.h:29] + 283 IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x1fb647b [ipc_message.h:129] + 283 content::RenderFrameHostImpl::OnMessageReceived(IPC::Message const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x59e2fd [render_frame_host_impl.cc:668] + 283 content::WebContentsImpl::OnMessageReceived(content::RenderFrameHostImpl*, IPC::Message const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x7fdaad [web_contents_impl.cc:0] + 283 extensions::ChromeExtensionWebContentsObserver::OnMessageReceived(IPC::Message const&, content::RenderFrameHost*) (in Google Chrome Framework) load address 0x114b3c000 + 0x3a77dd2 [chrome_extension_web_contents_observer.cc:92] + 283 extensions::ExtensionWebContentsObserver::OnMessageReceived(IPC::Message const&, content::RenderFrameHost*) (in Google Chrome Framework) load address 0x114b3c000 + 0x1223a7d [extension_web_contents_observer.cc:170] + 283 bool IPC::MessageT<ExtensionHostMsg_Request_Meta, std::__1::tuple<ExtensionHostMsg_Request_Params>, void>::Dispatch<extensions::ExtensionWebContentsObserver, extensions::ExtensionWebContentsObserver, content::RenderFrameHost, void (extensions::ExtensionWebContentsObserver::*)(content::RenderFrameHost*, ExtensionHostMsg_Request_Params const&)>(IPC::Message const*, extensions::ExtensionWebContentsObserver*, extensions::ExtensionWebContentsObserver*, content::RenderFrameHost*, void (extensions::ExtensionWebContentsObserver::*)(content::RenderFrameHost*, ExtensionHostMsg_Request_Params const&)) (in Google Chrome Framework) load address 0x114b3c000 + 0x1223b86 [ipc_message_templates.h:0] + 283 extensions::ExtensionFunctionDispatcher::Dispatch(ExtensionHostMsg_Request_Params const&, content::RenderFrameHost*, int) (in Google Chrome Framework) load address 0x114b3c000 + 0x120610c [callback_internal.h:130] + 283 extensions::ExtensionFunctionDispatcher::DispatchWithCallbackInternal(ExtensionHostMsg_Request_Params const&, content::RenderFrameHost*, int, base::Callback<void (ExtensionFunction::ResponseType, base::ListValue const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, extensions::functions::HistogramValue), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x12065f0 [memory:2586] + 283 ExtensionFunction::RunWithValidation() (in Google Chrome Framework) load address 0x114b3c000 + 0x1203e6f [string:1213] + 283 extensions::HidConnectFunction::Run() (in Google Chrome Framework) load address 0x114b3c000 + 0x12ef739 [callback_internal.h:130] + 283 device::HidServiceMac::Connect(unsigned long long const&, base::Callback<void (scoped_refptr<device::HidConnection>), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) (in Google Chrome Framework) load address 0x114b3c000 + 0x1369863 [hid_service_mac.cc:158] + 283 IOHIDDeviceCreate (in IOKit) + 334 [0x7fff94055a96] + 283 IOCreatePlugInInterfaceForService (in IOKit) + 1169 [0x7fff9402748c] + 283 IOHIDDeviceClass::start(__CFDictionary const*, unsigned int) (in IOHIDLib) + 76 [0x11c0175b8] + 283 IOServiceOpen (in IOKit) + 45 [0x7fff94025199] + 283 io_service_open_extended (in IOKit) + 129 [0x7fff9409fb50] + 283 mach_msg (in libsystem_kernel.dylib) + 55 [0x7fffa77c97d7] + 283 mach_msg_trap (in libsystem_kernel.dylib) + 10 [0x7fffa77ca38a]
,
Mar 29 2017
For reference, the issue is with the hardware the kernel logs something like this: default 18:00:59.008813 -0400 kernel 0 stalling for detach from IOUSBHostHIDDevice
,
Mar 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c2d8b871f3810ec01394eee986b02bc400b36db7 commit c2d8b871f3810ec01394eee986b02bc400b36db7 Author: reillyg <reillyg@chromium.org> Date: Thu Mar 30 23:16:41 2017 Open IOHIDDevices on the FILE thread Calling IOHIDDeviceCreate to open a HID device may jank the UI thread so the task should be executed on the FILE thread during the creation of a new HidConnection. BUG= 706573 Review-Url: https://codereview.chromium.org/2780393006 Cr-Commit-Position: refs/heads/master@{#460920} [modify] https://crrev.com/c2d8b871f3810ec01394eee986b02bc400b36db7/device/hid/hid_connection_mac.cc [modify] https://crrev.com/c2d8b871f3810ec01394eee986b02bc400b36db7/device/hid/hid_connection_mac.h [modify] https://crrev.com/c2d8b871f3810ec01394eee986b02bc400b36db7/device/hid/hid_service_mac.cc [modify] https://crrev.com/c2d8b871f3810ec01394eee986b02bc400b36db7/device/hid/hid_service_mac.h
,
Apr 17 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by rsesek@chromium.org
, Mar 29 2017Status: Assigned (was: Untriaged)