1851054 - Crash in [@ OOM | large | nsTArray_Impl<T>::AppendElementInternal | nsTArray<T>::AppendElement | mozilla::MediaTrackDemuxer::SamplesHolder::AppendSample ]

Status: NEW

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

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/2b9c3c80-2f33-4871-83cf-42d080230830

MOZ_CRASH Reason: out of memory: 0x0000000083A00000 bytes requested

Top 10 frames of crashing thread:

0  mozglue.dll  MOZ_Crash  mfbt/Assertions.h:281
0  mozglue.dll  mozalloc_abort  memory/mozalloc/mozalloc_abort.cpp:26
1  mozglue.dll  mozalloc_handle_oom  memory/mozalloc/mozalloc_oom.cpp:51
1  mozglue.dll  moz_xrealloc  memory/mozalloc/mozalloc.cpp:78
2  xul.dll  nsTArrayInfallibleAllocator::Realloc  xpcom/ds/nsTArray.h:259
2  xul.dll  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::EnsureCapacityImpl<nsTArrayInfallibleAllocator>  xpcom/ds/nsTArray-inl.h:221
3  xul.dll  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::EnsureCapacity  xpcom/ds/nsTArray.h:443
3  xul.dll  nsTArray_Impl<RefPtr<mozilla::MediaRawData>, nsTArrayInfallibleAllocator>::AppendElementInternal  xpcom/ds/nsTArray.h:2690
3  xul.dll  nsTArray<RefPtr<mozilla::MediaRawData> >::AppendElement  xpcom/ds/nsTArray.h:2833
3  xul.dll  mozilla::MediaTrackDemuxer::SamplesHolder::AppendSample  dom/media/MediaDataDemuxer.h:105

Some of these allocations are quite large. For instance, for this one it is 2GB.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 2

[Jim Mathies [:jimm]]

At the base of the stack -
mozilla::MediaTrackDemuxer::SamplesHolder::AppendSample

Comment 3

[Jim Mathies [:jimm]]

Hasn't shown up in 118 for some reason.

Comment 4

[Andrew McCreight [:mccr8]]

I made the signature a little nicer.

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Looking at:
https://crash-stats.mozilla.org/report/index/8a8ce576-f39a-4867-809c-6d2520240701

We OOM requesting 602,931,200 bytes for an array of RefPtr. That means 75,366,400 entries. If we assume 60 fps, that is 14.5 days worth of samples. Clearly something went wrong :).

We can ask for all the samples here:
https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/dom/media/mediasource/TrackBuffersManager.cpp#1644
https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/dom/media/mediasource/TrackBuffersManager.cpp#1682

Then in the loop, we won't exit until we've read all of the samples available, or we hit 0 (so roughly INT32_MAX samples):
https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/dom/media/mp4/MP4Demuxer.cpp#538

When we request another sample via GetNextSample, we may introduce a blocking read to advance:
https://searchfox.org/mozilla-central/rev/b368ed8b48c0ea8ed2f1948e4776a6fbb5976dff/dom/media/mp4/SampleIterator.cpp#390

Which means we will end up reading all of the samples if I understand this correctly, and if the stream is sufficiently long and/or high enough fps rate, we will always OOM on systems with insufficient memory?

Comment 6

[Andrew Osmond [:aosmond] (he/him)]

The regression must be in Firefox 123.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

Somewhere in this massive list:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?tochange=d3c71a6fc9a1aecf1fe04f8de2fc0b816588e677&fromchange=8f8b7a07d8a6721d87f1ae8e3699ee3b9e7f6168

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

This seems to be on the audio path specifically.