If at all possible, could you log an about:tracing trace of this behavior?

Are there any reports of this hang / crash in chrome://crashes?

Restarting my computer seems to fix it for a few hours (which I did this morning). I'll try to get a trace of the hang the next time that it happens.

This bug is pending feedback.

The problem went away for more than a week, but is now back. I disabled all extensions and flash, and logged out of my gmail account.

I enabled a trace through about:tracing and then went to chrome://settings to trigger the freeze. The trace window froze at 16% at the same time the chrome://settings window froze.

I've attached a stack trace from the OS though. I need to enable crash reporting before chrome://crashes will have any information, and will try to do that after a system restart, assuming that gets chrome working again as before.

Deleted: stacktrace.txt 62.7 KB

stacktrace.txt 62.7 KB View Download

I was able to enable crash reporting after the restart, and chrome://crashes now shows data, but nothing for the dates of the freezes.

Thank you for providing more feedback. Adding requester "ellyjones@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

rsesek@, I could use your help here. What's up with the UUID-named module in the attached stack trace? It shows up in loaded modules too:

  Binary Images:
         0x10e739000 -        0x10e739fff  com.google.Chrome 53.0.2785.116 (2785.116) <0F10A3A1-A65A-3567-8446-7400A794A3F5>  /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
         0x10e9a0000 -                ???  ???                                        <E0168049-5D98-3360-B97C-CD496DBC0D10>
      0x7fff81ad9000 -     0x7fff81f4ffff  com.apple.CoreFoundation 6.9 (1258.1)      <943A1383-DA6A-3DC0-ABCD-D9AEB3D0D34D>  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
      0x7fff82c2a000 -     0x7fff82c57fff  libdispatch.dylib (501.40.12)              <C7499857-61A5-3D7D-A5EA-65DCC8C3DF92>  /usr/lib/system/libdispatch.dylib
      0x7fff83ff9000 -     0x7fff84086fff  libsystem_c.dylib (1082.60.1)              <28733D22-553E-3CBC-8D2C-EDCEB46E46AF>  /usr/lib/system/libsystem_c.dylib
      0x7fff88682000 -     0x7fff889d6fff  com.apple.Foundation 6.9 (1259)            <71A9D3A0-0B1F-3E3A-86F3-1486365A6EF2>  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
      0x7fff8a87f000 -     0x7fff8a8d0fff  com.apple.audio.CoreAudio 4.3.0 (4.3.0)    <EA7D4F3B-062B-3C81-A98C-C89264D00D48>  /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
      0x7fff8bc66000 -     0x7fff8bc84fff  libsystem_kernel.dylib (3248.60.11)        <A3F069EA-6A41-35CA-BDF8-187E0209B3E2>  /usr/lib/system/libsystem_kernel.dylib
      0x7fff8f859000 -     0x7fff90482fff  com.apple.AppKit 6.9 (1404.47)             <F3411F6E-DD87-34D0-8C68-C69B2205E41D>  /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
      0x7fff9434b000 -     0x7fff94354fff  libsystem_pthread.dylib (138.10.4)         <3DD1EF4C-1D1B-3ABF-8CC6-B3B1CEEE9559>  /usr/lib/system/libsystem_pthread.dylib
      0x7fff9541d000 -     0x7fff95426fff  libsystem_notify.dylib (150.40.1)          <D48BDE34-0F7E-34CA-A0FF-C578E39987CC>  /usr/lib/system/libsystem_notify.dylib
      0x7fff973ce000 -     0x7fff976c3fff  com.apple.HIToolbox 2.1.1 (807.2)          <36413C45-36AF-34EF-9C0E-F18B31D1E565>  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
 *0xffffff7f80eaa000 - 0xffffff7f80eb3fff  com.apple.kec.pthread 1.0 (1)              <39D0B4EB-B7F4-3891-96C2-F8B886656C8A>  /System/Library/Extensions/pthread.kext/Contents/MacOS/pthread
 *0xffffff8000200000 - 0xffffff80009fffff  kernel (3248.60.11)                        <E349749B-3303-3DDF-959C-B5885A0E1F6E>  /System/Library/Kernels/kernel

The hot stack trace passes through that module, and the only search hit for the same UUID is this thread: https://productforums.google.com/forum/#!msg/chrome/iaPhqSC3Hps/NQh5Ojg0AQAJ which has Google Chrome Framework labelled with that UUID, so I guess that it is our framework, but why is the info missing in this stack trace?

Also, do you know how to get crsym to digest this crash?

crsym can't handle that format of spindump. But I was able to symbolize the relevant stack frames by doing the following:

1) Take the UUID for Chrome Framework (named ??? for whatever reason), delete the dashes, and add a '0' on the end. This can be used for the "Module Identifier" in crsym's Stack Fragment entry.
2) Look up the load address for that module in the "Binary Images" section
3) Copy the address you want to look up.

That gives me:

0x10ef23ec4 [Google Chrome Framework -	 message_pump_mac.mm:309] base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x10ef478ba [Google Chrome Framework +	 0x5a78ba] base::mac::CallWithEHFrame(void () block_pointer)
0x10ef244bd [Google Chrome Framework -	 message_pump_mac.mm:330] base::MessagePumpCFRunLoopBase::RunWork()
0x10ef51fbb [Google Chrome Framework -	 message_loop.cc:624] base::MessageLoop::DoWork()
0x10ef51c5c [Google Chrome Framework -	 message_loop.cc:502] base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&)
0x10ef5194c [Google Chrome Framework -	 vector:640] base::MessageLoop::RunTask(base::PendingTask const&)
0x10ef2f1bb [Google Chrome Framework -	 callback.h:389] base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask const&)
0x112679b4a [Google Chrome Framework -	 audio_input_device_manager.cc:176] content::AudioInputDeviceManager::EnumerateOnDeviceThread(content::MediaStreamType)
0x10ff02b5b [Google Chrome Framework -	 audio_manager_mac.cc:132] media::GetAudioDeviceInfo(bool, std::__1::list<media::AudioDeviceName, std::__1::allocator<media::AudioDeviceName> >*)

Which then leads to:

 41  AudioObjectGetPropertyDataSize + 140 (CoreAudio + 137362) [0x7fff8a8a0892] 1-41
   41  HALSystem::CheckOutInstance() + 147 (CoreAudio + 4615) [0x7fff8a880207] 1-41
     41  HALPlugInManagement::Initialize() + 306 (CoreAudio + 36832) [0x7fff8a887fe0] 1-41
       41  HALPlugInManagement::CreateHALPlugIn(HALCFPlugIn const*) + 1242 (CoreAudio + 41010) [0x7fff8a889032] 1-41
         41  HAL_HardwarePlugIn_InitializeWithObjectID(AudioHardwarePlugInInterface**, unsigned int) + 56 (CoreAudio + 45464) [0x7fff8a88a198] 1-41
           41  HALC_ShellPlugIn::ConnectToServer() + 24 (CoreAudio + 55838) [0x7fff8a88ca1e] 1-41
             41  HALC_ProxyObjectMap::CopyObjectByObjectID(unsigned int) + 67 (CoreAudio + 10087) [0x7fff8a881767] 1-41
               41  HALC_ProxyObjectMap::_CopyObjectByObjectID(unsigned int) + 21 (CoreAudio + 10277) [0x7fff8a881825] 1-41
                 41  HALC_ProxyObjectMap::_CreateSystemObject() + 38 (CoreAudio + 10642) [0x7fff8a881992] 1-41
                   41  HALC_ProxySystem::HALC_ProxySystem() + 536 (CoreAudio + 11266) [0x7fff8a881c02] 1-41
                     41  HALC_System_Open + 133 (CoreAudio + 186219) [0x7fff8a8ac76b] 1-41
                       41  mach_msg_trap + 10 (libsystem_kernel.dylib + 69490) [0x7fff8bc76f72] 1-41
                        *41  hndl_mach_scall64 + 22 (kernel + 2018694) [0xffffff80003ecd86] 1-41
                          *41  mach_call_munger64 + 410 (kernel + 1806026) [0xffffff80003b8eca] 1-41
                            *41  mach_msg_overwrite_trap + 197 (kernel + 861861) [0xffffff80002d26a5] 1-41
                              *41  ipc_kmsg_send + 323 (kernel + 797059) [0xffffff80002c2983] 1-41
                                *41  ipc_mqueue_send + 539 (kernel + 811403) [0xffffff80002c618b] 1-41
                                  *41  thread_block_reason + 175 (kernel + 986671) [0xffffff80002f0e2f] 1-41
                                    *41  ??? (kernel + 1000220) [0xffffff80002f431c] 1-41
                                      *41  machine_switch_context + 316 (kernel + 1875900) [0xffffff80003c9fbc] 1-41

As per #10, freeze happen at audio_input_device_manager.cc. Dale, can you take a look?

According tho this CL https://codereview.chromium.org/2350693002 device enumeration was removed from AudioInputDeviceManager recently.
Assigning to guidou@ to take a look.

This also may be related to Issue 647498.

Device enumeration was moved to MediaDevicesManager, but it will ultimately do the same thing as AIDM did, which is to call GetAudioDeviceInfo on the device thread on Mac.
It looks like something hanged while doing the OS-level operation.
Giving back to olka@ for further investigation.

In the middle of June, I had switched to using a Bluetooth headset -- Bose QC35. The problem first showed up in September though.

Were there any driver updates around that time?

Software installation logs attached. ITunes update on 8/2. El Capitan 10.11.6 was 8/15, and a security update for it on 9/2. That's all that I see that might be relevant.

Deleted: Ze29sha.png 141 KB

	Ze29sha.png 141 KB View Download

And you did not do any updates through Bose firmware update app? (If not, probably it's something you want to do?)

This looks like an audio driver hang, which results in browser UI thread hang. Are you still seeing it? Could you make sure that Bose firmware is up-to-date?

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919