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

RESOLVED FIXED in Firefox 51

Status

()

defect
P5
normal
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: emorley, Unassigned)

Tracking

({intermittent-failure})

Trunk
mozilla51
x86
Windows 8
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(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)

Details

Attachments

(1 attachment)

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)