Intermittent "###!!! ASSERTION: Track not found" in MediaEngineDefaultAudioSource::NotifyPull

RESOLVED FIXED in Firefox 45

Status

()

P2
normal
Rank:
25
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: pehrsons, Assigned: pehrsons)

Tracking

Trunk
mozilla45
Points:
---

Firefox Tracking Flags

(firefox45 fixed, firefox46 fixed)

Details

Attachments

(3 attachments)

(Assignee)

Description

3 years ago
The patch at [1] introduced a little race in MediaEngineDefaultAudioSource. In this case the audio track has ended but the stream is not finished so NotifyPull is still proxied through to the audio source.

We should keep track of when the audio track ends and tell the audio source so it can stop asking the SourceMediaStream for info on a track that does not exist.

[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/4c0e38d45f7b
(Assignee)

Updated

3 years ago
Assignee: nobody → pehrsons
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Summary: "###!!! ASSERTION: Track not found" in MediaEngineDefaultAudioSource::NotifyPull → Intermittent "###!!! ASSERTION: Track not found" in MediaEngineDefaultAudioSource::NotifyPull
(Assignee)

Comment 1

3 years ago
Created attachment 8685785 [details]
MozReview Request: Bug 1223655 - Only check for track end if track exists in MediaEngineDefaultAudioSource. r?jesup

Bug 1223655 - Only check for track end if track exists in MediaEngineDefaultAudioSource. r?jesup
Attachment #8685785 - Flags: review?(rjesup)
Comment on attachment 8685785 [details]
MozReview Request: Bug 1223655 - Only check for track end if track exists in MediaEngineDefaultAudioSource. r?jesup

https://reviewboard.mozilla.org/r/24911/#review22421
Attachment #8685785 - Flags: review?(rjesup) → review+

Comment 5

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b01d694885ed
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Version: 33 Branch → Trunk
Still seeing these, though with what feels like reduced frequency, e.g. https://treeherder.mozilla.org/logviewer.html#?job_id=2677135&repo=mozilla-central
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
22 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 17
* fx-team: 2
* b2g-inbound: 2
* mozilla-central: 1

Platform breakdown:
* android-4-3-armv7-api11: 8
* osx-10-10: 6
* windows7-32: 4
* osx-10-6: 3
* windows8-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-11-09&endday=2015-11-15&tree=all
(Assignee)

Comment 8

3 years ago
I know why - there's a mismatch between what is checked when we explicitly check for the track's existence in the StreamBuffer (FindTrackID) and what is checked by GetEndOfAppendedData().

What this means is basically that we'll assert if the track has ended but has not been removed from the StreamBuffer.
Flags: needinfo?(pehrsons)
19 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 13
* b2g-inbound: 3
* fx-team: 2
* mozilla-central: 1

Platform breakdown:
* osx-10-10: 6
* windows7-32: 5
* osx-10-6: 4
* android-4-3-armv7-api11: 4

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-11-16&endday=2015-11-22&tree=all
19 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 12
* fx-team: 4
* mozilla-central: 3

Platform breakdown:
* osx-10-6: 12
* windows7-32: 3
* osx-10-10: 2
* windows8-64: 1
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-11-23&endday=2015-11-29&tree=all
32 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 21
* fx-team: 7
* mozilla-central: 2
* b2g-inbound: 2

Platform breakdown:
* osx-10-6: 12
* osx-10-10: 7
* windows7-32: 6
* android-4-3-armv7-api11: 4
* windows8-64: 3

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-11-30&endday=2015-12-06&tree=all
Rank: 25
Priority: -- → P2
28 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 20
* try: 3
* fx-team: 2
* b2g-inbound: 2
* mozilla-central: 1

Platform breakdown:
* osx-10-6: 13
* android-4-3-armv7-api11: 4
* windows8-64: 3
* windows7-32: 3
* osx-10-10: 3
* windowsxp: 1
* b2g-device-image: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-12-07&endday=2015-12-13&tree=all
24 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 16
* mozilla-central: 5
* fx-team: 2
* mozilla-aurora: 1

Platform breakdown:
* osx-10-6: 11
* windows7-32: 5
* android-4-3-armv7-api11: 4
* windowsxp: 1
* windows8-64: 1
* osx-10-10: 1
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-12-14&endday=2015-12-20&tree=all
(Assignee)

Comment 14

3 years ago
Created attachment 8700948 [details] [diff] [review]
Also don't check time of data end if track has ended

This should do it.

GetEndOfAppendedData gives this error when the TrackData for the provided TrackID is not found. We set the StreamBuffer's Track struct to ended at the same time as we remove that TrackData, during an MSG iteration.
Flags: needinfo?(pehrsons)
Attachment #8700948 - Flags: review?(rjesup)

Updated

3 years ago
Attachment #8700948 - Flags: review?(rjesup) → review+

Comment 17

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f355522e9954
https://hg.mozilla.org/mozilla-central/rev/e98ed2bb333d
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
status-firefox45: fixed → affected
(Assignee)

Comment 18

3 years ago
Created attachment 8701732 [details] [diff] [review]
[Aurora-45] Also don't check time of data end if track has ended

This is a merge of the two last fixes that landed on 46, rebased on top of 45. Carries r=jesup.

Approval Request Comment
[Feature/regressing bug #]: First patch of this, bug 1223655
[User impact if declined]: Intermittent oranges on debug builds
[Describe test coverage new/current, TreeHerder]: Landed on m-c, fixed the current orange per [1].
[Risks and why]: No risk. Change only applies to debug builds on a feature we only use in testing.
[String/UUID change made/needed]: None

[1] https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-12-18&tree=mozilla-inbound
Attachment #8701732 - Flags: review+
Attachment #8701732 - Flags: approval-mozilla-aurora?
Attachment #8701732 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
9 automation job failures were associated with this bug in the last 7 days.

Repository breakdown:
* mozilla-inbound: 5
* mozilla-central: 1
* mozilla-aurora: 1
* fx-team: 1
* b2g-inbound: 1

Platform breakdown:
* osx-10-6: 4
* osx-10-10: 2
* android-4-3-armv7-api11: 2
* windows8-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1223655&startday=2015-12-21&endday=2015-12-27&tree=all

Comment 20

3 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/0786a97aee59
status-firefox45: affected → fixed
You need to log in before you can comment on or make changes to this bug.