Web Audio crashtests are very timeout-prone on B2G




5 years ago
3 years ago


(Reporter: RyanVM, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [blocking-webaudio-][leave open])



5 years ago
We have been fighting extremely frequent (near perma-fail) timeouts in the Web Audio crashtests on B2G. To date, we've already had to disable a few tests in the past, but that only bought us some time. I will soon be pushing another set of disablings. If that doesn't work, I'm afraid we're at a point where we're going to have to consider disabling the entire set of tests. Whack-A-Mole is not an effective strategy for dealing with test failures.

This bug is filed for finding the root cause of these failures, fixing it, and re-enabling the tests.

Comment 1

5 years ago
Consider this our last attempt at not disabling everything.
Whiteboard: [leave open]

Comment 3

5 years ago
jwwang, do you mind investigating this, please?  It sucks that we're skipping all of these tests on Firefox OS... :/
Assignee: nobody → jwwang


5 years ago
Blocks: 904707
Perhaps related to bug 908462.


5 years ago
Depends on: 908462

Comment 5

5 years ago
These have been flaky for awhile, but it seems that it started getting out of hand around Wednesday.


You can hit the green arrow at the bottom to show more jobs going back further.


5 years ago
Whiteboard: [leave open] → [blocking-webaudio-]
In the middle of other major issues. I will come back at this later.
Depends on: 910994
30 or so runs with 2e7089db4e86 reverted and CC debugging enabled are not reproducing:

40 or so runs with 2e7089db4e86 reverted and no CC debugging  didn't reproduce either https://tbpl.mozilla.org/?tree=Try&rev=be5f7bcdf2f5

This and comment 7 based on revision 8c5a94ba1096 plus some local patches.
Not certain this is related but crashtest 907986.html that I added on try is intermittently timing out only on B2G emulator.  CC timing shows that CC is happening but not taking more than a fraction of a second => the problem is not CC.
Thank you for your persistence with this! :-)
When 907986.html times out, the ScriptProcessorNode never gets the "audioprocess" event.

The audioprocess count logging in the logs of successful runs was to observe the MSG thread spamming the main thread with up to 100 more audioprocess events than the main thread wanted.

b2g_emulator_vm mozilla-inbound opt test crashtest-1 on 2013-09-04 15:41:47 PDT for push 4a5e5f94a4f7

TEST-UNEXPECTED-FAIL | | application timed out after 330 seconds with no output
(In reply to Karl Tomlinson (:karlt) from comment #11)
> When 907986.html times out, the ScriptProcessorNode never gets the
> "audioprocess" event.

That could be bug 916773.
Depends on: 916773
Repeated the experiments of comment 7 and 8, and still no timeouts:

So reenabled most tests.  880202.html is still disabled, not because I have reason to suspect that test, but because I missed that test in my experiments.  If there are no reports in the next few days, I'll look at enabling 880202.html.  At least crashtests should have stack traces on timeouts now.

Whiteboard: [blocking-webaudio-] → [blocking-webaudio-][leave open]
Blocks: 920338


5 years ago
Blocks: 896587
Priority: -- → P2
Release the bug so that someone can take it. I will continue working on media tests.
Assignee: jwwang → nobody
Priority: P2 → P3

Comment 17

3 years ago
These tests are mostly enabled on B2G today, and the few disabled tests have their own tracking bugs annotated in the manifest. Closing this out.
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.