1199676 - crash in mozilla::TrackBuffersManager::CheckNextInsertionIndex(mozilla::TrackBuffersManager::TrackData&, mozilla::media::TimeUnit const&)

Status: RESOLVED DUPLICATE of bug 1188238

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

Description

[Ludovic Hirlimann [:Usul]]

This bug was filed from the Socorro interface and is 
report bp-df16db0d-eed8-4773-b943-004a82150828.
=============================================================
 0 	libxul.so 	mozilla::TrackBuffersManager::CheckNextInsertionIndex(mozilla::TrackBuffersManager::TrackData&, mozilla::media::TimeUnit const&) 	dom/media/mediasource/TrackBuffersManager.cpp
1 	libxul.so 	mozilla::TrackBuffersManager::InsertFrames(nsTArray<nsRefPtr<mozilla::MediaRawData> >&, mozilla::media::TimeIntervals const&, mozilla::TrackBuffersManager::TrackData&) 	dom/media/mediasource/TrackBuffersManager.cpp
2 	libxul.so 	mozilla::TrackBuffersManager::ProcessFrames(nsTArray<nsRefPtr<mozilla::MediaRawData> >&, mozilla::TrackBuffersManager::TrackData&) 	dom/media/mediasource/TrackBuffersManager.cpp
3 	libxul.so 	mozilla::TrackBuffersManager::CompleteCodedFrameProcessing() 	dom/media/mediasource/TrackBuffersManager.cpp
4 	libxul.so 	mozilla::TrackBuffersManager::DoDemuxAudio() 	dom/media/mediasource/TrackBuffersManager.cpp
5 	libxul.so 	mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::MethodThenValue<mozilla::TrackBuffersManager, void (mozilla::TrackBuffersManager::*)(nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>), void (mozilla::TrackBuffersManager::*)(mozilla::DemuxerFailureReason)>::DoResolveOrRejectInternal(mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ResolveOrRejectValue const&) 	xpcom/threads/MozPromise.h
6 	libxul.so 	mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ThenValueBase::DoResolveOrReject(mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ResolveOrRejectValue const&) 	xpcom/threads/MozPromise.h
7 	libxul.so 	mozilla::MozPromise<nsRefPtr<mozilla::MediaTrackDemuxer::SamplesHolder>, mozilla::DemuxerFailureReason, true>::ThenValueBase::ResolveOrRejectRunnable::Run() 	xpcom/threads/MozPromise.h
8 	libxul.so 	mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() 	xpcom/threads/TaskDispatcher.h
9 	libxul.so 	mozilla::TaskQueue::Runner::Run() 	xpcom/threads/TaskQueue.cpp
10 	libxul.so 	nsThreadPool::Run() 	xpcom/threads/nsThreadPool.cpp
11 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
12 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
13 	libxul.so 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
14 	libxul.so 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
15 	libxul.so 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
16 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c
Ø 17 	libpthread-2.21.so 	libpthread-2.21.so@0x7554 	
Ø 18 	libc-2.21.so 	libc-2.21.so@0x102b9c


no better idea then firefox:general sorry.

Comment 1

[Ludovic Hirlimann [:Usul]]

This I believe was with and embeded video (from yourube) on www.miniwargaming.com, but I'm not sure.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I've tried a few videos from miniwargaming.com, but didn't get a crash.

Unfortunately, I cannot reproduce this issue without the video that crashed and/or knowing how it was played (resolution, seeking, etc.).
This crash happens after a sequence of previous add/remove frames put some data structures in bad shape, and these don't appear in the stack trace nor dump file.

So I probably won't be able to do anything with this. Reassigning to "nobody", if someone else has a better idea.

One thing we could do is add crash annotations before this MOZ_CRASH, which would capture relevant contents from the TrackData that caused the issue (and optionally some information about the calling InsertFrames method), potentially giving some useful details about what has gone wrong.

Comment 3

[Jean-Yves Avenard [:jya]]

this is more than likely a dupe of 1188238

The only way we can crash if we couldn't find a position to insert the new frame ; and this can only occur of the frame has a duration of 0. As we use Interval.Intersect() method to detect where to insert, this will fail with an "empty" interval.

Comment 4

[Jean-Yves Avenard [:jya]]

oh, and we would have had to seek