1982386 - Perma [tier 2] dom/media/test/crashtests/1045650.html | application timed out after 370 seconds with no output

Status: RESOLVED DUPLICATE of bug 1963163

(Core :: Audio/Video, defect)

Description

[agoloman]

Push with failures
Failure log

Comment 1

[Emilio Cobos Álvarez [:emilio]]

My patch is literally windows-only (ifdef'd out on other platforms), but the hanging test is on macOS, so pretty sure it's not related.

The failing test is https://searchfox.org/mozilla-central/source/dom/media/test/crashtests/1045650.html. Paul do you see anything suspicious? (ni?ing since it's an AudioContext crashtest).

This seems like bug 1941055 to me, other than that...

Comment 2

[Paul Adenot (:padenot)]

Yeah, not related. Maybe a deadlock, create_typed_audiounit in the log at https://firefoxci.taskcluster-artifacts.net/Qsg6nU7MSvmgSNNO--xjFw/0/public/logs/live_backing.log. Matthew, wasn't there something fishy with the main thread, audioipc and those maCOS system calls?

Comment 3

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1977581

Comment 4

[Stephen A Pohl]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

This seems like bug 1941055 to me, other than that...

Tentatively moving to Core : Audio/Video to confirm whether or not this is indeed a duplicate of bug 1941055.

Comment 5

[Matthew Gregan [:kinetik]]

This deadlock seems to be inside the cubeb-coreaudio backend, not really AudioIPC related. More specifically, creating VPIO units triggers CoreAudio activity that either needs to run on the serial queue (but it's blocked by stream initialization) or depends on a different lock ordering than the stream initialization path holds. I think this is the same issue as bug 1866595, so I'll bounce it over for Andreas for a closer look.

Comment 6

[Andreas Pehrson [:pehrsons]]

Looking at the log in comment 0 we are creating a vpio unit in the AudioIPC Server, which is running (sync) the serial dispatch queue on which we do all interactions with CoreAudio. All other threads involved in the deadlock (there are a handful) are managed by CoreAudio directly. I'm not sure how to mitigate this kind of platform issue but if anyone has thoughts I'm all ears.

What happens is probably that some previous test triggers the vpio creation that deadlocks and hangs. Then this test interacts with cubeb in some way involving a main thread, which then also gets blocked and causes the lack of output. It could be a content process main thread querying something from cubeb sync.

Easiest short-term fix may be to identify the crashtest triggering vpio, and disabling platform processing for it.

Comment 7

[Andreas Pehrson [:pehrsons]]

From the log's test order I'd assume 1028458.html is the offending test.

Comment 8

[Andreas Pehrson [:pehrsons]]

Not really a regression from bug 1963163, but adding for tracking. Bug 1963163 addressed an identical timeout but treated the symptom rather than the root cause - the previous test.

Comment 9

[Andreas Pehrson [:pehrsons]]

Actually bug 1963163 is still open so let's dupe this one instead, and fix it there.