This crash was found using decoders new libfuzzer media fuzzing interface (bug 1465407)

The attached test case can trigger the issue in a regular build if the test is reloaded multiple times.

==462== ERROR: libFuzzer: out-of-memory (used: 2447Mb; limit: 2048Mb)
   To change the out-of-memory limit use -rss_limit_mb=<N>

Live Heap Allocations: 2132491552 bytes in 33946 chunks; quarantined: 207722499 bytes in 1693 chunks; 52799 other chunks; total chunks: 88438; showing top 95% (at most 8 unique contexts)
1289750648 byte(s) (60%) in 1 allocation(s)
    #0 0x564ed1b409f3 in __interceptor_malloc /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
    #1 0x7fcf581edd73 in Malloc src/objdir-ff-fuzzing/dist/include/nsTArray.h:192:46
    #2 0x7fcf581edd73 in nsTArrayFallibleAllocator::ResultTypeProxy nsTArray_base<nsTArrayFallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayFallibleAllocator>(unsigned long, unsigned long) src/objdir-ff-fuzzing/dist/include/nsTArray-inl.h:144
    #3 0x7fcf61b778f9 in SetCapacity<nsTArrayFallibleAllocator> src/objdir-ff-fuzzing/dist/include/nsTArray.h:2008:47
    #4 0x7fcf61b778f9 in SetCapacity src/objdir-ff-fuzzing/dist/include/nsTArray.h:2015
    #5 0x7fcf61b778f9 in mozilla::Index::Index(mozilla::IndiceWrapper const&, mozilla::ByteStream*, unsigned int, bool) src/dom/media/mp4/Index.cpp:392
    #6 0x7fcf61b92fa9 in mozilla::MP4TrackDemuxer::MP4TrackDemuxer(mozilla::MediaResource*, mozilla::UniquePtr<mozilla::TrackInfo, mozilla::DefaultDelete<mozilla::TrackInfo> >&&, mozilla::IndiceWrapper const&) src/dom/media/mp4/MP4Demuxer.cpp:349:18
    #7 0x7fcf61b87b06 in mozilla::MP4Demuxer::Init() src/dom/media/mp4/MP4Demuxer.cpp:224:45
    #8 0x7fcf60e49d2b in mozilla::BenchmarkPlayback::DemuxSamples() src/dom/media/Benchmark.cpp:191:13
    #9 0x7fcf60e5c61b in operator() src/dom/media/Benchmark.cpp:145:59
    #10 0x7fcf60e5c61b in mozilla::detail::RunnableFunction<mozilla::Benchmark::Run()::$_2::operator()() const::'lambda'()>::Run() src/objdir-ff-fuzzing/dist/include/nsThreadUtils.h:564
    #11 0x7fcf582bbffb in mozilla::TaskQueue::Runner::Run() src/xpcom/threads/TaskQueue.cpp:199:12
    #12 0x7fcf582ff774 in nsThreadPool::Run() src/xpcom/threads/nsThreadPool.cpp:244:14
    #13 0x7fcf58300724 in non-virtual thunk to nsThreadPool::Run() src/xpcom/threads/nsThreadPool.cpp
    #14 0x7fcf582f33cb in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1225:14
    #15 0x7fcf582facc4 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:486:10
    #16 0x7fcf599541de in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:303:20
    #17 0x7fcf597c745e in RunInternal src/ipc/chromium/src/base/message_loop.cc:315:10
    #18 0x7fcf597c745e in RunHandler src/ipc/chromium/src/base/message_loop.cc:308
    #19 0x7fcf597c745e in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290
    #20 0x7fcf582eaf68 in nsThread::ThreadFunc(void*) src/xpcom/threads/nsThread.cpp:459:11
    #21 0x7fcf7fa02f48 in _pt_root src/nsprpub/pr/src/pthreads/ptthread.c:201:5
    #22 0x7fcf7f6336da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)

805307800 byte(s) (37%) in 8 allocation(s)
    #0 0x564ed1b40e0f in __interceptor_realloc /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165:3
    #1 0x7fcf6d3434d3 in _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::realloc::h3adb0d1861b634aa /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/liballoc/alloc.rs:166:21

I don't see what more we can do here.

We need to store the array of samples for plain mp4. For this we need to allocate an array.
Note that this allocation is normally fallible:
https://searchfox.org/mozilla-central/source/dom/media/mp4/Index.cpp#392

it will normally handle it gracefully. Why Asan choke on it is out of our control

If you were to open that file in a non-asan build it would behave as expected.