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

Issue 764502 link

Starred by 5 users

Issue metadata

Status: Verified
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Hang while switching resolution

Project Member Reported by borisv@chromium.org, Sep 12 2017

Issue description

Chrome Version: 63.0.3213.0
OS: macOS 10.12.6 (16G29)

What steps will reproduce the problem?
It happened while switching to external display with significantly larger resolution and adding plugging KVM to the USB. The KVM has keyboard and mouse

Chrome browser process hanged with the mouse cursor turning into spinning wheel. 
Activity monitor did not show Chrome process as a top CPU. Activitiy Monitor itself was the top CPU usage process.


 
ChromeHang.txt
147 KB View Download

Comment 1 by shrike@chromium.org, Sep 15 2017

Components: Blink>Media>Audio
[mac bug triage] According to the attached backtrace it looks like Chrome hung destroying an audio device. Setting component based on OWNERS file for audio_auhal_mac.*.
Components: -Blink>Media>Audio Internals>Media>Audio
Cc: dalecur...@chromium.org
borisv@, do you still repro this bug recently?
Dale@, do you see anything abnormal by looking at log? there is a call to
media::AUHALStream::Close() involved before hang.
Cc: ossu@chromium.org olka@chromium.org maxmorin@chromium.org

Comment 5 by ossu@chromium.org, Oct 3 2017

Owner: ossu@chromium.org
Status: Assigned (was: Untriaged)
This looks incredibly much like the CoreAudio deadlock I stumbled upon a couple of months ago, and have since reported to Apple:

- The com.apple.audio.IOThread.client thread is waiting in CAMutex::Lock(), trying to lock a mutex that the com.apple.audio.CADispatchQueue.SerialQueue thread is holding.
- That thread, on the other hand, is stuck in HALB_Mutex::Lock() trying to lock a mutex that the IOThread is holding.
- The main thread eventually gets stuck in HALB_Mutex::Lock() trying to lock the same mutex, which will never get released.

I'll take this bug for now.

Comment 6 by ossu@chromium.org, Oct 3 2017

Cc: grunell@chromium.org
Thank you, ossu@. I do not have a stable repro, but the issue seems to happen when I disconnect a USB-C connection for the monitor, which also has an audio output. The Mac was using the monitor audio as the default audio device. The monitor is ACER B326HK 32" monitor.

Comment 8 by ossu@chromium.org, Oct 18 2017

Status: ExternalDependency (was: Assigned)
Changing this to ExternalDependency; the problem seems to be under investigation by Apple.

Comment 9 by ossu@chromium.org, Dec 7 2017

Cc: rsesek@chromium.org
 Issue 792184  has been merged into this issue.

Comment 10 by ossu@chromium.org, Jan 8 2018

Status: Verified (was: ExternalDependency)
Checked that the fix is in macOS 10.13.2. Closing as verified.

Comment 11 by ossu@chromium.org, Jan 17 2018

Cc: guidou@chromium.org
 Issue 802404  has been merged into this issue.

Sign in to add a comment