Closed Bug 894922 Opened 11 years ago Closed 8 years ago

Intermittent Windows 8 media/test/test_bug448534.html | Test timed out. (during test case gizmo.mp4)

Categories

(Core :: Audio/Video: Playback, defect, P5)

x86
Windows 8
defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox24 --- disabled
firefox30 --- wontfix
firefox31 --- disabled
firefox32 --- disabled
firefox-esr24 --- disabled
b2g-v1.3 --- disabled
b2g-v1.3T --- disabled
b2g-v1.4 --- disabled
b2g-v2.0 --- disabled
firefox51 --- fixed

People

(Reporter: emorley, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

WINNT 6.2 mozilla-inbound opt test mochitest-1 on 2013-07-16 20:29:30 PDT for push ecfcb0796854 slave: t-w864-ix-019 https://tbpl.mozilla.org/php/getParsedLog.php?id=25360858&tree=Mozilla-Inbound { 20:40:49 INFO - 146013 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | [started detodos.opus-6] Length of array should match number of running tests 20:40:49 INFO - 146014 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | Video should not be paused while playing 20:40:49 INFO - 146015 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | Video should be paused after removing from the Document 20:40:49 INFO - 146016 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | [finished seek.webm-5] Length of array should match number of running tests 20:40:49 INFO - 146017 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | [started gizmo.mp4-7] Length of array should match number of running tests 20:40:49 INFO - 146018 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | Video should not be paused while playing 20:40:49 INFO - 146019 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | Video should be paused after removing from the Document 20:40:49 INFO - 146020 INFO TEST-PASS | /tests/content/media/test/test_bug448534.html | [finished detodos.opus-6] Length of array should match number of running tests 20:43:17 INFO - NOTE: child process received `Goodbye', closing down 20:43:17 INFO - WARNING: pipe error: 109: file e:/builds/moz2_slave/m-in-w32-000000000000000000000/build/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 299 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:43:17 INFO - NPP_Destroy 20:46:10 INFO - 146021 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_bug448534.html | Test timed out. }
This test is awful; someone needs to own and fix this. This test is *not* a test for bug448534. The first part of it is, and then there's an innocent-looking manager.runTests(gSmallTests, startTest); which then runs a bunch of unrelated small load tests. This is the part that often times out; it also happens to not print any output while it's running, making it impossible to debug what the hell is going on. The mess is spread throughout a bunch of the media tests, and the core mess-driver seems to be manifest.js. This is horrible; I understand the desire to decrease the number of discrete test runs, but all of these things (gSmallTests, gVideoTests, etc.) should have their own discrete test files so that when they fail or time out, we can blame the right thing. (Minor side note to whoever looks at this -- test_bug448534.html has a link to the wrong test in the header)
I filed bug 921269 -- that one seemed to be caused by the mp3 file. In a bunch of the failures above, the "short test" that didn't finish is always gizmo.mp4 . Both mp3 and mp4 are where we use the system decoders I believe, so that seems to be highly related.
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #123) > This test is awful; someone needs to own and fix this. > I don't think that you understand how the media tests work. But that's understandable, you don't work on media. > This test is *not* a test for bug448534. The first part of it is, and then > there's an innocent-looking > > manager.runTests(gSmallTests, startTest); Actually, that innocent looking line is what causes startTest() to be called, and it's startTest that runs the test. Without this line, the test does nothing. > which then runs a bunch of unrelated small load tests. I added these because at one stage there was a bug in the JS engine that caused JS arrays to forget what was in them, and I was aggressively being blamed for a bug in the JS engine. > This is the part > that often times out; runTests() should not time out, it should call the callback you pass it to start the first test. The callback you pass it (startTest in this case) could be failing, but typically they're straight line code, so they shouldn't fail unless there's a bug in the JS engine. If the callback isn't being called, then there's probably a bug in the JS engine. > it also happens to not print any output while it's > running, making it impossible to debug what the hell is going on. It prints output when the callback calls the manager back to say a test successfully started. And again when the script calls it back to say the test is finished. That said, it's easy to add more logging. > The mess > is spread throughout a bunch of the media tests, and the core mess-driver > seems to be manifest.js. > > This is horrible; I understand the desire to decrease the number of discrete > test runs, but all of these things (gSmallTests, gVideoTests, etc.) should > have their own discrete test files so that when they fail or time out, we > can blame the right thing. I don't believe you understand why we have the manager. We run tests across a list of different files because we have different backends for supporting different containers/codecs and we need to ensure behaviour is uniform across all of them. I have been thinking recently that we could trim the lists, but I haven't had time. We're all swamped at the moment. (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #124) > I filed bug 921269 -- that one seemed to be caused by the mp3 file. In a > bunch of the failures above, the "short test" that didn't finish is always > gizmo.mp4 . Both mp3 and mp4 are where we use the system decoders I > believe, so that seems to be highly related. There's a bug how we integrate into the Windows platform decoder. I spent months trying to fix it, but I can't read the Windows code so I wasn't able to figure out what assumption Windows was making that I was violating. I am now integrating a new software MP4 demuxer to fix the bug, but that will take time. This test can be disabled on Windows (only) until I get that landed. I also don't understand where the "ReferenceError: makeURI is not defined" error is coming from, it's showing up in a bunch of our recently filed oranges, but we didn't change anything recently.
Summary: Intermittent media/test/test_bug448534.html | Test timed out. → Intermittent media/test/test_bug448534.html on Windows 8; test case gizmo.mp4 | Test timed out.
Summary: Intermittent media/test/test_bug448534.html on Windows 8; test case gizmo.mp4 | Test timed out. → Intermittent Windows 8 media/test/test_bug448534.html | Test timed out. (during test case gizmo.mp4)
Almost a year since being filed and still happening on a regular basis. Do we have any theories as to why this seems to only affect Win8? From comment 125, it appears this stalled on out someone who understands the Windows media code looking into it? Anthony, is there anybody on your team that can help here? :)
Flags: needinfo?(ajones)
We're intending to bypass Windows Media Foundation's demuxer and use the one landed in bug 908503. This should give us better control over decoders and help eliminate the orange issues. There is still a fair amount of work before we get there.
Flags: needinfo?(ajones)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #340) > We're intending to bypass Windows Media Foundation's demuxer and use the one > landed in bug 908503. This should give us better control over decoders and > help eliminate the orange issues. There is still a fair amount of work > before we get there. OK, I'm disabling the test on Windows for now then. We can revisit it once that work is completed.
Whiteboard: [test disabled on Windows][leave open]
Component: Audio/Video → Audio/Video: Playback
P5
Keywords: leave-open
Priority: -- → P5
Whiteboard: [test disabled on Windows][leave open] → [test disabled on Windows]
(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #365) > Created attachment 8786167 [details] > Bug 894922 - Enable test case on windows. . > > Review commit: https://reviewboard.mozilla.org/r/74910/diff/#index_header > See other reviews: https://reviewboard.mozilla.org/r/74910/ Bug 908503 already be landed over 2 years. Try to enable this test case to see the orange issue eliminated or not.
(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #366) > (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #365) > > Created attachment 8786167 [details] > > Bug 894922 - Enable test case on windows. . > > > > Review commit: https://reviewboard.mozilla.org/r/74910/diff/#index_header > > See other reviews: https://reviewboard.mozilla.org/r/74910/ > > Bug 908503 already be landed over 2 years. Try to enable this test case to > see the orange issue eliminated or not. Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e933f96e8a14
Attachment #8786167 - Flags: review?(jwwang) → review+
Keywords: leave-open
Whiteboard: [test disabled on Windows]
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/autoland/rev/c218b89925e0 Enable test case on windows. r=jwwang.
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: