New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 647116 link

Starred by 1 user

Issue metadata

Status: ExternalDependency
Owner:
OOO Dec 22 - Jan 8
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 672469

Blocking:
issue 669773



Sign in to add a comment

Chrome Hangs if coreaudiod is not responding

Reported by kmbarag...@gmail.com, Sep 15 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce the problem:
1. sudo killall -v -STOP coreaudiod
2. Notice that chrome has now become completely unresponsive, and may never wake up.
3. sudo killall -v -CONT coreaudiod
4. Notice that chrome responds again

What is the expected behavior?
It seems like better behavior if the application can continue in the face of audio daemon errors.

What went wrong?
Chrome is completely unresponsive during the period that coreaudiod is not responding. 

Did this work before? No 

Chrome version: 52.0.2743.116  Channel: n/a
OS Version: OS X 10.11.6
Flash Version: Shockwave Flash 22.0 r0

These sorts of errors really happen, particularly on sleep/wake cycles.

May be tangentially related to 160920, but I don't see any mention of hanging there, only lack of audio.
 
Status: ExternalDependency (was: Unconfirmed)
The stack is:

   libsystem_kernel.dylib`mach_msg_trap + 10
   libsystem_kernel.dylib`mach_msg + 55
   CoreAudio`HALC_Object_GetPropertyData_DI32 + 125   CoreAudio`HALC_ProxyObject::GetPropertyData(...
   CoreAudio`HALDefaultDeviceProperty::GetData(...
   CoreAudio`AudioObjectGetPropertyData + 262 
   libmedia.dylib`media::GetDefaultDevice(...
   libmedia.dylib`media::GetDefaultOutputDevice(...
   libmedia.dylib`media::AudioManagerMac::GetDefaultOutputDeviceID(... 
   libmedia.dylib`media::AudioManagerBase::GetDefaultOutputStreamParameters(...
   libcontent.dylib`content::(...
   libcontent.dylib`content::AudioOutputDeviceInfo base::internal::FunctorTraits<content::AudioOutputDeviceInfo (...
   libcontent.dylib`content::AudioOutputDeviceInfo base::internal::InvokeHelper<false, content::AudioOutputDeviceInfo>::MakeItSo<content::AudioOutputDeviceInfo (...
   libcontent.dylib`content::AudioOutputDeviceInfo base::internal::Invoker<base::internal::BindState<content::AudioOutputDeviceInfo (...
   libcontent.dylib`base::internal::Invoker<base::internal::BindState<content::AudioOutputDeviceInfo (...
   libcontent.dylib`base::internal::RunMixin<base::Callback<content::AudioOutputDeviceInfo (...
   libcontent.dylib`void base::internal::ReturnAsParamAdapter<content::AudioOutputDeviceInfo>(...
   libcontent.dylib`void base::internal::FunctorTraits<void (...

And it appears that AudioObjectGetPropertyData just hangs forever... marking ExternalDependency

I also noticed that Terminal gets similarly wedged (but seems to recover).

Comment 2 by tapted@chromium.org, Nov 30 2016

Blocking: 669773
Components: Internals>Media
Cc: ossu@chromium.org

Comment 5 by ossu@chromium.org, Feb 13 2018

Cc: olka@chromium.org
The big question I think is: what would we do in this case? It's unfortunate that we seem to have to run CoreAudio calls on the main thread. The Audio Process work done by olka@ and team (hello!) should ensure Chrome in general doesn't hang in cases like these. Before that, I don't see it worth pursuing.

If we're able to detect such hangs, what ought the user-facing result be? Just no audio? A message about coreaudiod having stoppped working and a request to restart it or the whole machine? 

Comment 6 by olka@chromium.org, Feb 15 2018

Blockedon: 672469

Comment 7 by olka@chromium.org, Feb 15 2018

Cc: -olka@chromium.org grunell@chromium.org dalecur...@chromium.org maxmorin@chromium.org marinaciocea@chromium.org
Owner: olka@chromium.org

Sign in to add a comment