Closed Bug 1321198 Opened 5 years ago Closed 5 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | dom/media/test/test_seek-4.html | application timed out after 330 seconds with no output

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1331070

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Component: Audio/Video → Audio/Video: Playback
JW, I got a fair amount of those after I rebased bug 1319992 on top of the current autoland, so I would get the changes of bug 

The value I rebased on was commit 3a64450cc56a11645148cf396768e0bc56c90953
Prior to this, I could run the media mochitests with bug 1319992 using a74bd474c1a6f4f5cafc3e5e80cf923bb343bfd3 as tip without issues.

Ever since, I've been unable to run locally the media mochitests (using --repeat 10) without either a timeout or an unexpected results (typically related to the readyState not being the expected value) and including this particular one: "dom/media/test/test_seek-4.html | application timed out after 330 seconds with no output "


So there was a regression occurring between 3a64450cc56a11645148cf396768e0bc56c90953 and a74bd474c1a6f4f5cafc3e5e80cf923bb343bfd3

I won't be able to have a look before flying to Hawaii tomorrow.
Flags: needinfo?(jwwang)
Bug 1321082 and bug 1321081 also happen on Win8.

https://treeherder.mozilla.org/logviewer.html#?job_id=40104703&repo=mozilla-inbound#L5173
22:34:01     INFO - [GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057
22:34:01     INFO - [GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057
22:34:01     INFO - [GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057

Any idea?
Flags: needinfo?(jwwang) → needinfo?(matt.woodrow)
We fail to allocate a D3D texture when the size is 0,0, that seems expected.

We should also fallback to trying a non-d3d11 texture in this case too, so it's not obvious that this would break anything.

It looks like the 'gizmo.mp4' sub-test of test_seek-4 never completes for some reason.

The regression range jya sees is:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a74bd474c1a6f4f5cafc3e5e80cf923bb343bfd3&tochange=3a64450cc56a11645148cf396768e0bc56c90953

Maybe bug 1319706? That looks like it changed seeking behaviour.
Flags: needinfo?(matt.woodrow)
Comment on attachment 8825691 [details]
Bug 1321198 - this is a debugging patch which crashes when test_seek* time out to get the stack trace about what's stuck.

https://reviewboard.mozilla.org/r/103808/#review104732
Attachment #8825691 - Flags: review?(jyavenard) → review+
Thanks for the review!
Pushed by jwwang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f69ae549623a
this is a debugging patch which crashes when test_seek* time out to get the stack trace about what's stuck. r=jya
Backed out in https://hg.mozilla.org/integration/autoland/rev/cf9282be7d8625245bc98e8eac0013f08aae18fe

Might I recommend that you push things which should only be pushed to Try only to Try, and not to integration branches which you will then make unmergeable for five hours?
What build errors did the patch cause?
Flags: needinfo?(philringnalda)
(In reply to Phil Ringnalda (:philor) from comment #11)
> Backed out in
> https://hg.mozilla.org/integration/autoland/rev/
> cf9282be7d8625245bc98e8eac0013f08aae18fe
> 
> Might I recommend that you push things which should only be pushed to Try
> only to Try, and not to integration branches which you will then make
> unmergeable for five hours?

The repro rate is low so I need to push the change (which crash intentionally on mochitest timeout to generate the debugging info I need) to the integration branch so I can collect debugging info from the bot maybe one or two weeks later.
Flags: needinfo?(philringnalda)
(In reply to Phil Ringnalda (:philor) from comment #15)
> Well, if the rate was low then you must have also increased the timeout rate
> with your patch somehow, because
> https://treeherder.mozilla.org/#/
> jobs?repo=autoland&tochange=cf9282be7d8625245bc98e8eac0013f08aae18fe&fromchan
> ge=f69ae549623a21b626365a83a85bb8009e8e5bd7&filter-
> searchStr=ed40db35f04ace3986de7cec91e72ce0318379a2&group_state=expanded is
> not at all a low rate.

Fair enough. Please backout the change and I will try my luck with Try to see if I can repro the issue.
(In reply to Jean-Yves Avenard [:jya] from comment #1)
> JW, I got a fair amount of those after I rebased bug 1319992 on top of the
> current autoland, so I would get the changes of bug 

https://treeherder.mozilla.org/logviewer.html#?job_id=68393200&repo=try&lineNumber=11149
Finally I was able to repro the issue on Try.

[MediaPlayback #2]: D/MediaSample Decoder=156b4ea8c0 OnVideoNotDecoded aError=2154692612
The log shows there was a decode error while seeking and that's why seek couldn't finish and the test case timed out. I believe this is also responsible for all test_seek-* timeouts.

Btw, aError=2154692612 is NS_ERROR_DOM_MEDIA_DECODE_ERR and this error happens on Windows 8 x64 opt only.

Hi Jya,
Do you have any idea about this error?
Flags: needinfo?(jyavenard)
WARNING: Decoder=a585838a0 Decode error=2154692612 message=ProcessOutput: MFTManager::Output:80004005
The error message with MediaResult::Message() printed.
no idea sorry...

I have seen try machines sometimes reporting that they don't support decoding anymore.
Flags: needinfo?(jyavenard)
See Also: → 1331281, 1330880
Is there a chance we can look at this in the next week, we have identified this as the root cause for bug 1331070 which is one of our top intermittents and suspect this is the cause of two other bugs.
Flags: needinfo?(jwwang)
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(jwwang)
Resolution: --- → DUPLICATE
Duplicate of bug: 1331070
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.