1532290 - MOZ_RELEASE_ASSERT(mStart <= mEnd) (Invalid Interval) failure in [@ mozilla::WebMDemuxer::GetBuffered]

Status: RESOLVED DUPLICATE of bug 1530897

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

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-8bebc394-697a-4649-8d7b-fb0e00190303.

Seen while looking at nightly crash stats: https://bit.ly/2C5BMy8

Crashes started in Build 20190301201651. Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98d4803bb2de7fcdb0096ddeedaefd29d0fd5fd4&tochange=3b08a133c893b960f15e014a8f36c954d31fda34

Top 10 frames of crashing thread:

0 xul.dll class mozilla::media::TimeIntervals mozilla::WebMDemuxer::GetBuffered dom/media/webm/WebMDemuxer.cpp:949
1 xul.dll class mozilla::media::TimeIntervals mozilla::WebMTrackDemuxer::GetBuffered dom/media/webm/WebMDemuxer.cpp:1225
2 xul.dll void mozilla::WebMTrackDemuxer::Reset dom/media/webm/WebMDemuxer.cpp:1159
3 xul.dll nsresult mozilla::detail::RunnableFunction<`lambda at z:/task_1551475619/build/src/dom/media/MediaFormatReader.cpp:800:9'>::Run xpcom/threads/nsThreadUtils.h:562
4 xul.dll nsresult mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:199
5 xul.dll nsresult nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:241
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1166
7 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:482
8 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:333
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308

Comment 1

[Karl Tomlinson (:karlt)]

Some stacks are in MediaFormatReader::DemuxerProxy::Wrapper::UpdateBuffered(). e.g.

https://crash-stats.mozilla.com/report/index/644bfc81-7939-407a-a46b-b24620190304

Comment 2

[Jean-Yves Avenard [:jya]]

This is not P1, there's max one a day, and will only crash in nightly

Comment 3

[Pascal Chevrel:pascalc]

Marking as fix-optional for 67 given the very low volume of crashes. I'd take a safe uplift in early beta if a fix comes up.

Comment 4

[Neha Kochar [:neha]]

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Comment 5

[Patricia Lawless]

jya: we're seeing crashes in beta for this one. Do you have any updates?

Comment 6

[Neha Kochar [:neha]]

No crashes seen on 66, so this seems to be a regression introduced in 67 beta.

Comment 7

[Jean-Yves Avenard [:jya]]

the crashstack in the original report is nonsensical (it can't crash where it says it does).

The assertion is a diagnostic assert, it won't crash in release.

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I'm fairly confident this is bug 1530897. As noted in comment 7, the crash stacks appear nonsensical as we're crashing on a line that constructs an empty interval[0]. I observed the same issue while debugging bug 1530897 locally, and this it's down to code optimization and symbolization. While it looks like we're returning an empty interval, it's actually that we're returning a non empty interval constructed in the later lines of code, and that the opt + symbolization has merged the return paths and shows the earlier one.

[0] https://hg.mozilla.org/mozilla-central/file/569826c0fd47a0e196057500c0873fab31253b70/dom/media/webm/WebMDemuxer.cpp#l958