Crash report: https://crash-stats.mozilla.org/report/index/e8abed67-2318-4558-a41d-e7f3f0240702

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mStart <= mEnd) (Invalid Interval)

Top 10 frames:

0  xul.dll  mozilla::media::Interval<mozilla::media::TimeUnit>::Interval<mozilla::media::...  dom/media/Intervals.h:48
1  xul.dll  mozilla::TrackBuffersManager::RemoveFrames(mozilla::media::TimeIntervals cons...  dom/media/mediasource/TrackBuffersManager.cpp:2541
2  xul.dll  mozilla::TrackBuffersManager::InsertFrames(nsTArray<RefPtr<mozilla::MediaRawD...  dom/media/mediasource/TrackBuffersManager.cpp:2299
3  xul.dll  mozilla::TrackBuffersManager::ProcessFrames(nsTArray<RefPtr<mozilla::MediaRaw...  dom/media/mediasource/TrackBuffersManager.cpp:2188
4  xul.dll  mozilla::TrackBuffersManager::CompleteCodedFrameProcessing()  dom/media/mediasource/TrackBuffersManager.cpp:1733
5  xul.dll  RefPtr<mozilla::TrackBuffersManager>::assign_assuming_AddRef(mozilla::TrackBu...  mfbt/RefPtr.h:65
5  xul.dll  RefPtr<mozilla::TrackBuffersManager>::operator=(void*)  mfbt/RefPtr.h:180
5  xul.dll  mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozill...  xpcom/threads/MozPromise.h:746
6  xul.dll  mozilla::MozPromise<bool, mozilla::MediaResult, 1>::ThenValueBase::DoResolveO...  xpcom/threads/MozPromise.h:621
6  xul.dll  mozilla::MozPromise<bool, mozilla::MediaResult, 1>::ThenValueBase::ResolveOrR...  xpcom/threads/MozPromise.h:488

There seem to be a steady trickle of these on Nightly, and no open bug with the signature (the last one was filed in September 2023), so I'm filing this. This did show up in the spike report, but there were just 5 in one build which could be a fluke.

12 crashes in the last month across all channels. 4 of them have URLs, all Twitch.

All 12 of those crashes are on Nightly 129, so it does seem like there could be some small regression here.

The first buildid I see for the 129 crashes is 20240620213827, though it isn't happening in every build, so it might have been introduced a day or two earlier.

If this happen after 0620, it could be caused by bug 1878510. I will take a look on it.

The two assertion failures shortly after 06/20 were in MP4SampleIndex::ConvertByteRangesToTimeRanges(mozilla::media::IntervalSet<long long> const&) from MP4TrackDemuxer::GetBuffered() and in ToMicrosecondResolution() from HTMLMediaElement::Buffered().

Since changes for bug 1903974, the assertion failures have been in two call sites in TrackBuffersManager::RemoveFrames().

RemoveFrames() has a history of buffered ranges that are inconsistent with TrackBuffer sample intervals, so the assertion failures there might have the same root cause.

In bug 1906667, I'm adding mozilla::media::Interval<T> to the prefix list, so the signatures will be split into different call sites.

Setting 1878510 as the regressor based on Comment 4, please correct if needed

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

Is there a user-facing impact from this bug which would make us want to track this for releases where diagnostic asserts aren't going to be hit?

No, it doesn't need to be tracked on Release. Likely the timestamp we parse for webm is still not accurate, which is something we want to further improve in bug 1903466.

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.