Closed Bug 906752 Opened 12 years ago Closed 3 years ago

Intermittent test_audioBufferSourceNodeOffset.html | Correct number of samples received (expected: 24000, actual: 32512)

Categories

(Core :: Web Audio, defect, P4)

Product:
Core
Component:
Web Audio
Platform:
x86
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
97 Branch
Tracking Flags:
Tracking Status
firefox24 --- fixed
firefox25 --- fixed
firefox97 --- fixed

People

(Reporter: RyanVM, Assigned: RyanVM)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Bug 906752 - Re-enable some tests in dom/media/webaudio.
48 bytes, text/x-phabricator-request
Details | Review
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from bug 895720 comment #21) > Ok, it just seems so fragile to me. Indeed. https://tbpl.mozilla.org/php/getParsedLog.php?id=26722910&tree=Mozilla-Inbound Ubuntu VM 12.04 mozilla-inbound debug test mochitest-1 on 2013-08-19 08:25:47 PDT for push cba433799e1b slave: tst-linux32-ec2-049 09:20:56 INFO - 153594 INFO TEST-START | /tests/content/media/webaudio/test/test_audioBufferSourceNodeOffset.html 09:20:56 INFO - System JS : ERROR (null):0 09:20:56 INFO - uncaught exception: 2147746065 09:20:56 INFO - ++DOMWINDOW == 26 (0xa24cd00) [serial = 4792] [outer = 0xbf3ba60] 09:20:57 INFO - System JS : ERROR (null):0 09:20:57 INFO - uncaught exception: 2147746065 09:20:57 INFO - 153595 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/webaudio/test/test_audioBufferSourceNodeOffset.html | Correct number of samples received (expected: 24000, actual: 32512). 09:20:57 INFO - 153596 INFO TEST-END | /tests/content/media/webaudio/test/test_audioBufferSourceNodeOffset.html | finished in 937ms 09:20:57 INFO - ++DOMWINDOW == 27 (0xd3dded0) [serial = 4793] [outer = 0xbf3ba60] 09:20:57 INFO - System JS : ERROR (null):0 09:20:57 INFO - uncaught exception: 2147746065
Has this decreased in frequency or is it too early to tell? (It looked like it was happening a lot between end of August and end of September and has since been seen much less often -- twice in the last month.) Did we change anything that could explain this?
Priority: -- → P2
Something has made this spike on B2G in the last couple days. My first thought is fallout somehow from bug 916135?
Flags: needinfo?(jwwang)
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #68) > Something has made this spike on B2G in the last couple days. My first > thought is fallout somehow from bug 916135? All recent failures happened in B2g and test_audioBufferSourceNodeOffset.html was disabled in B2G until bug 916135 was landed. It could be the test would have failed in B2G if not disabled.
Flags: needinfo?(jwwang)
Hi JW -- I believe you're working on this already. I've raised it to a P1 due to its frequency in the last week.
Assignee: nobody → jwwang
Priority: P2 → P1
Rob, Karl, Paul -- I believe JW is on holiday this week for Chinese New Year. Any idea why this bug would suddenly have spiked in frequency since Jan 23? I'd hate to see this test get disabled. Thanks.
Flags: needinfo?(roc)
Flags: needinfo?(paul)
Flags: needinfo?(karlt)
The reason this "started" on Jan 23 is because all media mochitests had been disabled on B2G until then. So this has probably been flaky all along but we just didn't see it. Personally, I don't think re-disabling it for now is a horrible option since it would just be going back to where things had already been.
Ryan -- Thanks for the background. I'm still coming up to speed on B2G. Given the frequency, I think it makes sense to disable this until JW has time to look at this. Can you disable this for us? (I'm also clearing the needinfos for Paul and Karl.)
Flags: needinfo?(ryanvm)
Flags: needinfo?(paul)
Flags: needinfo?(karlt)
OS: Linux → Gonk (Firefox OS)
https://hg.mozilla.org/integration/mozilla-inbound/rev/4e7bf8e9f208 Media mochitests are already disabled on debug B2G (bug 962871 tracks them being re-enabled), so the above push is opt-only.
Flags: needinfo?(ryanvm)
Whiteboard: [test disabled on B2G][leave open]
I am still fixing timeouts in mochitest. Giving the logs here, I am not sure if this bug is related to timeout issues. I would put my focus on fixing as many Intermittent-oranges (especially for timeouts) as possible before coming back to this constant-orange.
P2 for now, but we will come back to this.
Priority: P1 → P2
Blocks: 888271
The ScriptProcessor with small buffer dispatches directly to the main thread event loop, spamming the main thread with events every 5-6ms of graph processing, regardless of what happens on the main thread. PrepareUpdatesToMainThreadState may not do its part is notifying the main thread about the AudioBufferSourceNode stream finishing until the graph has been processing for 20 ms after the AudioBufferSourceNode ends. That notification is placed on the end of the main thread event queue. When the main thread eventually processes the event, it places a new event on the end of the main thread event queue, which now contains more audioprocess notifications. So, if the main thread gets behind on its audioprocess workload, more audioprocess notifications will sneak in ahead of the event that eventually dispatches the ended event. That may be a bug in the design. These failures seem to be happening in debug builds. It is not surprising that the main thread of a debug build cannot keep up, given the current design, and so these failures are expected. I suggest disabling the test on debug builds at least. Bug 888271 can be tested in a way that doesn't depend on the timing of audioprocess and ended events.
Release the bug. Haven't had time to investigate it...
Assignee: jwwang → nobody
The entire content/media/webaudio/test directory has been skipped on Android 2.3 bug 981889. With recent fixes, those tests can now be run, except for this test, as seen in Comments 271-276. Since this is a frequent failure on Android 2.3 and also occurs on Android 4.0 Debug, I disabled this on all Android (landed in bug 981889).
Whiteboard: [test disabled on B2G][leave open] → [test disabled on B2G and Android][leave open]
Sigh. Some words disappeared from my previous comment. To be clear: The entire webaudio directory has historically been skipped on Android 2.3, as tracked in bug 981889. In order to run the tests in the webaudio directory reliably, I had to disable test_audioBufferSourceNodeOffset.html on Android -- see bug 981889.
(In reply to Karl Tomlinson (back July 17 :karlt) from comment #174) > I suggest disabling the test on debug builds at least. > Bug 888271 can be tested in a way that doesn't depend on the timing of > audioprocess and ended events. How would you do that? If that could be done, that would mean this bug could be fixed. Or perhaps add a timer after the onended event so debug builds are more likely to catch up? Note that this test is still running on tbpl on debug builds, it should still be disabled?
(In reply to Martijn Wargers [:mwargers] (QA) from comment #311) > (In reply to Karl Tomlinson (back July 17 :karlt) from comment #174) > > I suggest disabling the test on debug builds at least. > > Bug 888271 can be tested in a way that doesn't depend on the timing of > > audioprocess and ended events. > > How would you do that? I don't know how to disable on debug builds only. The signal received by the ScriptProcessorNode can be checked against expected output without using / waiting for an onended event. Many of the tests in content/media/webaudio/test check the output of a Web Audio graph using the framework provided in webaudio.js. Using the same framework here would probably be tidiest. > Or perhaps add a timer after the onended event so debug builds are > more likely to catch up? I don't think that would help. It would just provide more time for the script processor to count more samples. > Note that this test is still running on tbpl on debug builds, it should > still be disabled? Yes.
(In reply to Karl Tomlinson (back July 17 :karlt) from comment #326) > I don't know how to disable on debug builds only. See http://hg.mozilla.org/mozilla-central/annotate/42c6a5418370/content/media/webaudio/test/mochitest.ini#l37 I think we probably want something like: [test_audioBufferSourceNodeOffset.html] skip-if = debug || (toolkit == 'gonk') || (toolkit == 'android') #bug 906752
Do we have any idea why this fails so often in e10s mode? Clearly we can't blame slave performance when we don't have any issues on the slaves in !e10s mode.
Flags: needinfo?(paul)
Disabled on debug builds per comment 174. https://hg.mozilla.org/integration/mozilla-inbound/rev/bce7864c1cdf https://hg.mozilla.org/releases/mozilla-aurora/rev/49d46c29fc9d https://hg.mozilla.org/releases/mozilla-beta/rev/d94be43c729c
Whiteboard: [test disabled on B2G and Android][leave open] → [test disabled on Android, B2G, and all debug builds][leave open]
Sorry I don't have time to look at this at the moment.
Flags: needinfo?(paul)
Priority: P2 → P3
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4

NI myself to see if we can un-skip this on debug builds these days.

Flags: needinfo?(ryanvm)
Whiteboard: [test disabled on Android, B2G, and all debug builds][leave open]
Assignee: nobody → ryanvm
Status: NEW → ASSIGNED
Pushed by rvandermeulen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/76fcc731f453 Re-enable some tests in dom/media/webaudio. r=padenot

https://hg.mozilla.org/mozilla-central/rev/76fcc731f453

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox97: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: