1415788 - Crash in mozilla::dom::HTMLMediaElement::InitializeDecoderForChannel

Status: RESOLVED FIXED

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

Description

[JW Wang [:jwwang] [:jw_wang]]

+++ This bug was initially created as a clone of Bug #1407148 +++

This bug was filed from the Socorro interface and is 
report bp-f6ec5b1e-f22b-4af3-bf87-e68680171009.
=============================================================

There are 15 crashes in nightly 58 starting with buildid 20171009100134. In analyzing the backtrace, the regressoin may have been introduced by patch [1] to fix bug 1402584.
The crash reason is always MOZ_RELEASE_ASSERT(mReadyState == nsIDOMHTMLMediaElement::HAVE_NOTHING).

[1] https://hg.mozilla.org/mozilla-central/rev?node=a4466933d251bca22688a859c108eb11772401c2

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

https://crash-stats.mozilla.com/report/index/9980818c-0366-4e98-84ae-fcb5f0171018

Bug 1407148 has fixed the assertion, but we still have some memory bugs.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Just to mirror from bug 1407148: the memory errors (UAF/wildptrs) include EXEC failures, and predate the assertion bug this is cloned from.  Low volume, but go back a ways.

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

JW - this is a sec-critical. Do you agree with that assessment? Can you find someone to figure out what is going on?

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

The volume is quite low on 56. I think it is not as critical as it was. I will keep an eye on this bug however I have no idea how to progress this bug since a UAF might be caused by any memory bug in the whole codebase.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #4)
> The volume is quite low on 56. I think it is not as critical as it was. I
> will keep an eye on this bug however I have no idea how to progress this bug
> since a UAF might be caused by any memory bug in the whole codebase.

UAF is rarely due to memory-trashing per se, and that would be most common in a "sweep" function like GC/CC.  There's something specific to this signature I suspect, and most of the crashes come from related source lines for the specific release, and the wildptr EXEC addresses seem to have a distinctive pattern.  Looking at the generated code there or a crashdump may help.

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

Any double-free in the whole codebase could result in a UAF in our media stack. The patterns are similar is because they all happen while loading media. However, since loading media involves lots of code (media, network, IPC...), it is still very hard to identify the location of double-free even if it is some piece of code in the media module (which is huge).

Comment 7

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Double-free can be caused by a using non-threadsafe refcounting.

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

I believe we have assertions to detect if AddRef()/Release() is called on the wrong thread.

Comment 9

[Blake Wu [:bwu][:blakewu]]

From crash report website regarding those 3 crash signature [1][2][3], the latest crash we got is FennecAndroid 58.0a1 20171018. It looks like we have not got new crashes for around 1 month. 
So I am going to close this bug. 

[1]https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Adom%3A%3AHTMLMediaElement%3A%3AInitializeDecoderForChannel&date=%3E%3D2017-11-15T17%3A03%3A07.000Z&date=%3C2017-12-15T17%3A03%3A07.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1 

[2]https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Adom%3A%3AHTMLMediaElement%3A%3AInitializeDecoderAsClone&date=%3E%3D2017-11-15T09%3A03%3A14.000Z&date=%3C2017-12-15T09%3A03%3A14.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#reports 

[3]https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Adom%3A%3AHTMLMediaElement%3A%3AAssertReadyStateIsNothing&date=%3E%3D2017-11-15T09%3A03%3A20.000Z&date=%3C2017-12-15T09%3A03%3A20.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1#reports