Open Bug 1554808 Opened 5 years ago Updated 10 months ago

Intermittent test_streams_element_capture.html | Caught exception for ambisonics.mp4-58: Error: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual mozilla::MediaResult mozilla::FFmpegAudioDecoder<55>::DoDecode(mozilla::MediaRawData *, uint8_t *

Categories

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

Product:
Core
Component:
Audio/Video
Type:
defect

Tracking

()

Status:
ASSIGNED
Tracking Flags:
Tracking Status
firefox-esr102 --- affected
firefox-esr115 --- affected
firefox114 --- affected
firefox115 --- affected
firefox116 --- affected
firefox117 --- affected

People

(Reporter: intermittent-bug-filer, Assigned: pehrsons)

References

(Depends on 1 open bug, Regression)

Details

(Keywords: intermittent-failure, leave-open, regression, Whiteboard: [stockwell disabled])

Attachments

(1 file)

Bug 1554808 - Disabled test_streams_element_capture.html on all platforms. r=jmaher
47 bytes, text/x-phabricator-request
Details | Review

Filed by: ncsoregi [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=248621894&repo=autoland
Full log: https://queue.taskcluster.net/v1/task/C_SU8CRAS0S-GvWvAByLfg/runs/0/artifacts/public/logs/live_backing.log

[task 2019-05-27T21:38:58.088Z] 21:38:58 INFO - TEST-PASS | dom/media/test/test_streams_element_capture.html | Reason cannot be empty
[task 2019-05-27T21:38:58.089Z] 21:38:58 INFO - Buffered messages finished
[task 2019-05-27T21:38:58.096Z] 21:38:58 INFO - TEST-UNEXPECTED-FAIL | dom/media/test/test_streams_element_capture.html | Caught exception for ambisonics.mp4-58: Error: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual mozilla::MediaResult mozilla::FFmpegAudioDecoder<55>::DoDecode(mozilla::MediaRawData , uint8_t , int, bool , mozilla::MediaDataDecoder::DecodedData &): FFmpeg audio error:-1094995529
[task 2019-05-27T21:38:58.098Z] 21:38:58 INFO - SimpleTest.ok@SimpleTest/SimpleTest.js:275:18
[task 2019-05-27T21:38:58.099Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:112:7
[task 2019-05-27T21:38:58.099Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.100Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.100Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.101Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.101Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.102Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.102Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.102Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.102Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.103Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.104Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.105Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.105Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.106Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.107Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.107Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.108Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.108Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.109Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - asyncMediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.110Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.111Z] 21:38:58 INFO - @dom/media/test/test_streams_element_capture.html:114:13
[task 2019-05-27T21:38:58.111Z] 21:38:58 INFO - async*MediaTestManager/this.nextTest@dom/media/test/manifest.js:1834:12
[task 2019-05-27T21:38:58.111Z] 21:38:58 INFO - MediaTestManager/this.finished@dom/media/test/manifest.js:1813:12
[task 2019-05-27T21:38:58.111Z] 21:38:58 INFO - [finished ambisonics.mp4-58] remaining= opus-mapping2.mp4-60
[task 2019-05-27T21:38:58.111Z] 21:38:58 INFO - TEST-PASS | dom/media/test/test_streams_element_capture.html | [finished ambisonics.mp4-58 t=84.556] Length of array should match number of running tests

Pushed by dvarga@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3177490c6c0f
Disabled test_streams_element_capture.html on all platforms. r=jmaher
Keywords: leave-open
Whiteboard: [stockwell disable-recommended] → [stockwell disabled]
See Also: → 1483259

This test was disabled without my knowledge, and it came as a surprise to me now, 16 months later. Similarly in bug 1557901.

Joel, what's the procedure here? Aren't devs supposed to be notified before their tests are disabled?

Flags: needinfo?(jmaher)
Assignee: nobody → apehrson
Status: NEW → ASSIGNED

Thanks for asking, it is a valid question and concern you have. We have a bot that detects when a failure rate is too high and we add a whiteboard tag of stockwell-disable-recommended, this gets picked up in a query the code sheriffs look at daily and will work to write patches for disabling. Typically they will:

  1. query all disable-recommended bugs
  2. needinfo the triage owner
  3. write a patch and ask for review from intermittent-reviewers
  4. reviewer should check this is disabling the least amount possible and that there is a needinfo
  5. land patch

there are edge cases here, typically when the triage owner is not reachable (i.e. on PTO and not accepting needinfo requests). The relationship between test<->dev depends on the triage owner (which is determined by the bugzilla component found in the related moz.build file for the test case)

Once in a while a test is disabled with both the code sheriff and the reviewer overlooking the need for a needinfo set (or a recent comment saying it is ok to disable).

As this was almost 1.5 years ago, I am not sure if :bryce was the triage owner back then nor if as triage owner there was an option for needinfo. I do not see any indicates of a needinfo in the bug history.

Flags: needinfo?(jmaher)

Thanks, Joel. That's very useful.

I think drno was triage owner back then, and our team calendar shows he was off the week this was disabled. Oh well.

do you have ideas of how to make this better? a backup triage owner field we could create? I think this happens about <5% of the time, but that is still often enough to consider a solution.

Loose thoughts:

If the number is low enough to allow a human touch: look at either

  • the changelog of the failing test and find someone who touched it recently, though I imagine that might give false positives or find people who have since quit, or
  • people.m.o for a colleague of the triage owner, and notify them
  • the modules list for a peer of the component the bug is under

For an automated approach: retry the needinfo every week for the then triage owner until the bug is closed, preferably with a bot..

Or patch bugzilla so that if a triage owner blocks needinfos they have to set a backup triage owner to proceed. That might be the leanest. Was this close to what you were thinking of?

those are all good ideas- I have had problems with the changelog in the past, it helps if I have recently interacted with someone in the changelog. a peer or manager would be good or a backup triage owner via bugzilla.

I am cleaning up a bunch of outdated triage owners this week, I will think on this some more and include an attempt in the docs for needinfo as part of the triage cleanup! Thanks for the ideas.

Thanks for taking ownership!

Severity: normal → S3
See Also: → 1557901
Depends on: 1838365
See Also: → 1555148
Depends on: 1839502

Timing of report coincides with https://bugzilla.mozilla.org/show_bug.cgi?id=1546655#c34

Regressed by: 1546655

Set release status flags based on info from the regressing bug 1546655

status-firefox114: --- → affected
status-firefox115: --- → affected
status-firefox116: --- → affected
status-firefox-esr102: --- → affected
Depends on: 1840498

Set release status flags based on info from the regressing bug 1546655

status-firefox117: --- → affected
status-firefox-esr115: --- → affected
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: