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.
Consider this our last attempt at not disabling everything. https://hg.mozilla.org/integration/b2g-inbound/rev/2e7089db4e86
Whiteboard: [leave open]
jwwang, do you mind investigating this, please? It sucks that we're skipping all of these tests on Firefox OS... :/
Assignee: nobody → jwwang
Perhaps related to bug 908462.
These have been flaky for awhile, but it seems that it started getting out of hand around Wednesday. https://tbpl.mozilla.org/?jobname=b2g_emulator_vm%20mozilla-central%20opt%20test%20crashtest-1 You can hit the green arrow at the bottom to show more jobs going back further.
In the middle of other major issues. I will come back at this later.
30 or so runs with 2e7089db4e86 reverted and CC debugging enabled are not reproducing: https://tbpl.mozilla.org/?tree=Try&rev=bf6bdabf1476
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. https://hg.mozilla.org/try/rev/d7318bb842af https://tbpl.mozilla.org/php/getParsedLog.php?id=27309980&tree=Try&full=1#error2
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. https://tbpl.mozilla.org/?tree=Try&rev=6bedbed18eaf
https://tbpl.mozilla.org/php/getParsedLog.php?id=27398230&tree=Mozilla-Inbound#error2 b2g_emulator_vm mozilla-inbound opt test crashtest-1 on 2013-09-04 15:41:47 PDT for push 4a5e5f94a4f7 TEST-UNEXPECTED-FAIL | http://10.0.2.2:8888/tests/content/media/test/crashtests/876249.html | 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: https://tbpl.mozilla.org/?tree=Try&rev=2b9ca7dcbbf6 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. https://hg.mozilla.org/integration/mozilla-inbound/rev/70cf74d59b55
Whiteboard: [blocking-webaudio-] → [blocking-webaudio-][leave open]
Release the bug so that someone can take it. I will continue working on media tests.
Assignee: jwwang → nobody
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.