1318999 - Crash in mozilla::TaskQueue::Dispatch: MOZ_RELEASE_ASSERT(aFailureHandling == DontAssertDispatchSuccess || ((bool)(!!(!NS_FAILED_impl(rv)))))

Status: RESOLVED FIXED

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

Description

[Nicholas Nethercote [inactive]]

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?

Comment 1

[Nicholas Nethercote [inactive]]

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

Comment 2

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

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&)

Comment 3

[Jean-Yves Avenard [:jya]]

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.

Comment 4

[Matt Woodrow (:mattwoodrow)]

Attachment: Revoke callback pointer during 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.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b22bbf4b9948
Revoke MediaDataDecoder callback after RemoteVideoDecoder has been shut down. r=jya

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b22bbf4b9948

Comment 7

[Nicholas Nethercote [inactive]]

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?

Comment 8

[Matt Woodrow (:mattwoodrow)]

(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.