Bugzilla

Comment 2

•

5 years ago

Let's wait for the test-case.

Flags: needinfo?(padenot)

Updated

•

5 years ago

status-firefox68: affected → wontfix

status-firefox69: --- → wontfix

status-firefox70: --- → affected

status-firefox71: --- → affected

status-firefox-esr68: --- → affected

Comment 3

•

5 years ago

I don't think we are going to get a test case for this. This issue is reported frequently but almost all of the test cases result in a hang or very long pause where the browser is unresponsive before closing. Even if we could get a test case that does repo the issue it would take a very long time to reduce if at all.

I did manage to get an rr trace that captures an abort after a long hang. Hopefully this is enough to get an idea of what is happening. The Pernosco session can be found here: https://pernos.co/debug/tbNBE_fdMkHAxiPZf-745Q/index.html

It would be great to get this fixed since this is a fuzz blocker on one of our most important fuzzers.

Flags: needinfo?(padenot)

Comment 4

•

5 years ago

Tyson, this is very useful thanks.

Assignee: nobody → padenot

Flags: needinfo?(padenot)

Comment 5

•

5 years ago

•

Edited

Paul, any chance you can have a look at this and if not could you possibly redirect it to someone else? This issue is a fuzzblocker and is limiting the performance of a fuzzer.

status-firefox70: affected → wontfix

status-firefox72: --- → affected

Flags: needinfo?(padenot)

Comment 6

•

5 years ago

Andreas, do you think you could have a look at this? There is a recording.

Flags: needinfo?(padenot) → needinfo?(apehrson)

Assignee

Comment 7

•

5 years ago

I've requested for the pernosco database to be rebuilt so I can take a look.

Assignee

Comment 8

•

5 years ago

Hmm, though I'm not sure we need it. This is an old classic (we saw it on B2G or Android emulator?) showing its face again. Many many graphs were created during a relatively short time. Short enough that they're not getting GCed. That, or something is blocking them from getting GCed. Then at shutdown they all get shut down at the same time, including their nsThreads. nsThread::Shutdown spins the event loop until the thread is done shutting down. But spinning the event loop will shut down the next graph's nsThread, and on it goes, higher and higher up the stack.

I'll take a look at whether there's something unexpected happening in the recording, but chances are we need to handle a legit case of this.

Assignee

Comment 9

•

5 years ago

There's only one graph involved, so yeah this is very unexpected.

These SystemClockDrivers are all fallbacks, so something in that code appears broken. We shouldn't switch from a fallback driver back to an audio driver. We switch here and this code does not check whether the current driver is a fallback driver.

Bug 1289678 comment 2 sheds some light on this in that the fallback mechanism was put in place so that we don't over-report errors, not to prevent flip-flopping between an audio driver and a clock driver.

I am currently looking into moving the fallback mechanism around in bug 1586370 and might make it so that once there's an error we avoid flip-flopping, because the graph will still think it's on the audio driver. Do you have any concerns with this, Paul?

Flags: needinfo?(apehrson) → needinfo?(padenot)

Assignee

Comment 10

•

5 years ago

FWIW the fallback happens because the graph's output channel count is 0, because cubeb returns CUBEB_ERROR when queried for its max channel count. See https://pernos.co/debug/tbNBE_fdMkHAxiPZf-745Q/index.html#f{m[AVCH,qmM_,t[UQ,OEE_,f{e[AVCH,qlw_,s{af28gxKAA,bAWI,oIIoQQw,uIIlN/g___

Assignee

Comment 11

•

5 years ago

I'm not sure where to look to see what's happening in the server. Kinetik, could you take a look?

Flags: needinfo?(kinetik)

Comment 12

•

5 years ago

Tyson, do you know if the machine here have audio capabilities?

Flags: needinfo?(padenot) → needinfo?(twsmith)

Comment 13

•

5 years ago

(In reply to Andreas Pehrson [:pehrsons] from comment #9)

Do you have any concerns with this, Paul?

It's pretty useful to recover from transient errors, would be nice if the graph would re-try periodically to re-open an audio driver if it needs one. But clearly it can be better than the current situation.

Comment 14

•

5 years ago

(In reply to Paul Adenot (:padenot) from comment #12)

Tyson, do you know if the machine here have audio capabilities?

Tyson checked on those host (different from the regular treeherder linux hosts), and they do not run the PulseAudio daemon.

Flags: needinfo?(kinetik)

Updated

•

5 years ago

Flags: needinfo?(twsmith)

Assignee

Comment 15

•

5 years ago

(In reply to Paul Adenot (:padenot) from comment #13)

(In reply to Andreas Pehrson [:pehrsons] from comment #9)

Do you have any concerns with this, Paul?

It's pretty useful to recover from transient errors, would be nice if the graph would re-try periodically to re-open an audio driver if it needs one. But clearly it can be better than the current situation.

Cool, I can make something work, but with some back-off logic so that we try more and more seldom if the problems continue.

I'll run with "media.cubeb.force_null_context" when testing, that should be able to repro. Per pernosco it could take some 2 minutes, but we'll see.

Assignee: padenot → apehrson

Status: NEW → ASSIGNED

Assignee

Updated

•

4 years ago

Depends on: 1586370

Assignee

Comment 16

•

4 years ago

I wasn't able to reproduce this, but I could observe flip-flopping drivers at a very high rate. With bug 1586370 and the patch (to come soon) here that rate is way down. The initial (100ms) and max (30s) rates of the back-off logic is very much up for bikeshedding.

https://hg.mozilla.org/mozilla-central/rev/cb00f09b36fc

Assignee

Comment 17

•

4 years ago

Attached file Bug 1542321 - Re-init a failed audio driver at increasing intervals. r?padenot — Details

Depends on D56085

Pulsebot

Comment 18

•

4 years ago

Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/cb00f09b36fc
Re-init a failed audio driver at increasing intervals. r=padenot

Oana Pop-Rus

Comment 19

•

4 years ago

bugherder

Status: ASSIGNED → RESOLVED

Closed: 4 years ago

status-firefox73: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → mozilla73