1664138 - Crash in [@ InvalidArrayIndex_CRASH | mozilla::TrackBuffersManager::GetSample]

Status: NEW

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

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

422 crashes in the last 3 months across all versions.

Crash report: https://crash-stats.mozilla.org/report/index/66a838ae-6266-4fa9-a08e-873780200908

Top 10 frames of crashing thread:

0 xul.dll InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:27
1 xul.dll mozilla::TrackBuffersManager::GetSample dom/media/mediasource/TrackBuffersManager.cpp:2718
2 xul.dll mozilla::MediaSourceTrackDemuxer::DoGetSamples dom/media/mediasource/MediaSourceDemuxer.cpp:426
3 xul.dll mozilla::detail::ProxyRunnable<mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, 1>, RefPtr<mozilla::MozPromise<RefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::MediaResult, 1> >  xpcom/threads/MozPromise.h:1457
4 xul.dll mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158
5 xul.dll nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:299
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1242
7 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:327
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309

Comment 1

[Jean-Yves Avenard [:jya]]

This indicates two possibilities : 1
1- somehow the first frame wasn't marked as a keyframe. Which it must always be.

It's unlikely to be a container error as when adding a new sample to the track buffer, it must be a keyframe, all frames returned by the demuxer that aren't keyframes would have been dropped.
https://searchfox.org/mozilla-central/source/dom/media/mediasource/TrackBuffersManager.cpp#1756-1771

there's code to check on that too.
https://searchfox.org/mozilla-central/source/dom/media/mediasource/TrackBuffersManager.cpp#1585-1604

And we deleted a sample, we always do so from keyframe to keyframe.

2- mNextGetSampleIndex was negative.
should modify that assert to be MOZ_RELEASE_ASSERT(trackData.mNextGetSampleIndex.isSome() &&
trackData.mNextGetSampleIndex.ref() < track.Length() && *trackData.mNextGetSampleIndex >= 0);
to track that one.

the latter is more likely I believe.

Comment 2

[Jon Bauman [:jbauman:]]

jya: any thoughts on priority/severity here?

Comment 3

[Jean-Yves Avenard [:jya]]

(In reply to Jon Bauman [:jbauman:] from comment #2)

jya: any thoughts on priority/severity here?

We have multiple bugs for that problem, I don't know why we created a new one.

I can't make sense of this bug, it's theorically not possible for it to happen whichever way you look at it. Almost everyone in the media team had a good at it one way or another and couldn't explain on why.

it's a low frequency bug and it's been there forever.

So P4/P5 as it triggers assert anyway

Comment 4

[Gabriele Svelto [:gsvelto]]

This seems to be spiking on Android and all the crashes seem to be missing the MOZ_Crash() reason. I hope that bug 1776197 is going to solve this.