This bug was filed from the Socorro interface and is report bp-15c8d396-1e8c-47e6-a269-a904a2161120. ============================================================= This crash signature, from this MOZ_RELEASE_ASSERT failure, has been around in low volumes for a long time. But there is a recent spike starting in Nightly 20161116030212. Mostly Windows, though I did see two Linux crashes. Here's a search for all of these assertion failures in the past three months: https://crash-stats.mozilla.com/search/?moz_crash_reason=~MOZ_RELEASE_ASSERT%28aFailureHandling&product=Firefox&date=%3E%3D2016-08-21T05%3A11%3A03.000Z&date=%3C2016-11-21T05%3A11%3A03.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature The regression range for the Nov 16 Nightly is here: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5e76768327660437bf3486554ad318e4b70276e1&tochange=79feeed4293336089590320a9f30a813fade8e3c The only media-related thing I can see is bug 1298027, which doesn't look all the relevant, though I am no media expert. jya, any ideas?

Bug 1317576 is another possibility? Not sure. NI'ing JW Wang too.

0 mozilla::TaskQueue::Dispatch(already_AddRefed<nsIRunnable>, mozilla::AbstractThread::DispatchFailureHandling, mozilla::AbstractThread::DispatchReason) 1 mozilla::MediaFormatReader::Output(mozilla::TrackInfo::TrackType, mozilla::MediaData*) 2 mozilla::dom::VideoDecoderChild::RecvOutput(mozilla::dom::VideoDataIPDL const&)

Matt, looks related to the OOP decoder outputting data after shutdown was called. I thought the flushing should have fixed that? It's puzzling because the DecoderFactory, that does flush the decoder upon destruction is deleted in Shutdown.

The patch that makes Flush synchronous hasn't landed yet (was fixing review comments). This change was meant to go in earlier but got lost during a rebase. The idea is that even if Flush gets missed, this should make it impossible to have a dangling pointer and attempt callbacks after the reader has shutdown. I'll get the sync Flush patch landed asap too.

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b22bbf4b9948 Revoke MediaDataDecoder callback after RemoteVideoDecoder has been shut down. r=jya

This is down from its peak but there's still some occurrences, e.g. in Nightly 20161202030204: https://crash-stats.mozilla.com/signature/?build_id=20161202030204&product=Firefox&release_channel=nightly&_sort=-date&platform=Windows&signature=mozilla%3A%3ATaskQueue%3A%3ADispatch&date=%3E%3D2016-12-02T00%3A00%3A00.000Z&date=%3C2016-12-05T01%3A17%3A00.000Z mattwoodrow, do they look related?

(In reply to Nicholas Nethercote [:njn] from comment #7) > This is down from its peak but there's still some occurrences, e.g. in > Nightly 20161202030204: > > https://crash-stats.mozilla.com/signature/ > ?build_id=20161202030204&product=Firefox&release_channel=nightly&_sort=- > date&platform=Windows&signature=mozilla%3A%3ATaskQueue%3A%3ADispatch&date=%3E > %3D2016-12-02T00%3A00%3A00.000Z&date=%3C2016-12-05T01%3A17%3A00.000Z > > mattwoodrow, do they look related? Nope, the stack there isn't obviously related to RemoteVideoDecoder. Looks like someone scheduled a tail dispatch and then shut down the target thread before we actually sent it.