1725130 - Crash in [@ arena_dalloc | free | nsTArray_Impl<T>::ClearAndRetainStorage | nsTArray_Impl<T>::~nsTArray_Impl | mozilla::MozPromise<T>::~MozPromise]

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/44add122-0b04-44c8-9bc4-667f80210811

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT((run->mRegionsMask[elm] & (1U << bit)) == 0) (Double-free?)

Top 10 frames of crashing thread:

0 libmozglue.so arena_dalloc memory/build/mozjemalloc.cpp:3372
1 libmozglue.so free memory/build/malloc_decls.h:54
2 libxul.so nsTArray_Impl<RefPtr<mozilla::MediaData>, nsTArrayInfallibleAllocator>::ClearAndRetainStorage xpcom/ds/nsTArray.h:1482
3 libxul.so nsTArray_Impl<RefPtr<mozilla::MediaData>, nsTArrayInfallibleAllocator>::~nsTArray_Impl xpcom/ds/nsTArray.h:1037
4 libxul.so mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>::~MozPromise xpcom/threads/MozPromise.h:1170
5 libxul.so mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>::Private::~Private xpcom/threads/MozPromise.h:256
6 libxul.so mozilla::RemoteDataDecoder::ReturnDecodedData dom/media/platforms/android/RemoteDataDecoder.cpp:797
7 libxul.so mozilla::RemoteVideoDecoder::ProcessOutput dom/media/platforms/android/RemoteDataDecoder.cpp:311
8 libxul.so mozilla::detail::RunnableMethodImpl<mozilla::RemoteVideoDecoder*, void  xpcom/threads/nsThreadUtils.h:1203
9 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158

All the crashes here are be double frees, even the ones missing the crash reason (those are because of bug 1666383). Daniel, this feels potentially security-sensitive so I'm filing it as such but I'm not 100% sure how to handle these cases. More importantly I stumbled upon this crash signature by looking at the ones in bug 1689329 which seems related. All the crashes in that bug are UAFs but it has not been flagged as security-sensitive. Given this is in the media decoding code I feel this might be a particularly sensitive area so I don't want to leave any public comments around pointing at it.

Comment 1

[Daniel Veditz [:dveditz]]

This might not be a regression, but a signature change

Comment 2

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

This bears some similarity to bug 1712615. Android specific and similar stacks. John, do you have time to look at these?

Both stacks appear to be trying to resolve a promise using a moved mDecodedData here. I wonder if we're double moving, or moving our decoded data after it's already freed?

Comment 3

[John Lin [:jhlin][:jolin]]

The issue was fixed in bug 1725470 and there has been no occurrence since 93. Closing this bug.