1263505 - crash in `anonymous namespace''::stream_start_one_side

Status: RESOLVED FIXED

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

Description

[Nicholas Nethercote [inactive]]

This bug was filed from the Socorro interface and is 
report bp-9826cfc8-9ab1-42f6-9159-63f1c2160409.
=============================================================

This has happened 6 times in the past 7 days. Each occurrence appears to be a different user:

> 0 	xul.dll 	`anonymous namespace'::stream_start_one_side 	media/libcubeb/src/cubeb_wasapi.cpp
> 1 	xul.dll 	`anonymous namespace'::wasapi_stream_start 	media/libcubeb/src/cubeb_wasapi.cpp
> 2 	xul.dll 	mozilla::AudioStream::Resume() 	dom/media/AudioStream.cpp
> 3 	xul.dll 	mozilla::media::DecodedAudioDataSink::SetPlaying(bool) 	dom/media/mediasink/DecodedAudioDataSink.cpp
> 4 	xul.dll 	mozilla::media::AudioSinkWrapper::SetPlaying(bool) 	dom/media/mediasink/AudioSinkWrapper.cpp
> 5 	xul.dll 	mozilla::media::VideoSink::SetPlaying(bool) 	dom/media/mediasink/VideoSink.cpp
> 6 	xul.dll 	mozilla::MediaDecoderStateMachine::MaybeStartPlayback() 	dom/media/MediaDecoderStateMachine.cpp
> 7 	xul.dll 	mozilla::MediaDecoderStateMachine::RunStateMachine() 	dom/media/MediaDecoderStateMachine.cpp

Almost certain related to the recent libcubeb update (bug 1251502).

Comment 1

[Nicholas Nethercote [inactive]]

kinetik, any ideas?

Comment 2

[Matthew Gregan [:kinetik]]

I think this is the same root cause as bug 1262345.

Comment 3

[Matthew Gregan [:kinetik]]

Should be fixed by bug 1262345, which landed in bug 1264594.

Comment 4

[Nicholas Nethercote [inactive]]

It's still happening, and seems to have gotten worse:

- Nightly 20160415030231 has 42 crashes so far (#2 topcrash for that build)

- Nightly 20160416030220 has 41 crashes so far (#1 topcrash for that build)

- Nightly 20160417030601 has 8 crashes so far (#1 topcrash for that build)


(In reply to Matthew Gregan [:kinetik] from comment #3)
> Should be fixed by bug 1262345, which landed in bug 1264594.

Bug 1264594 landed 3 days ago and it's still happening in Nightly builds done after that, so this hypothesis appears to be false :(

Comment 5

[Matthew Gregan [:kinetik]]

Ugh, this is embarrassing.  My patch has a trivial mistake in it:

  1756    HRESULT hr = OUTPUT ? stm->output_client->Start() : stm->input_client->Start();

...should be...

  1756    HRESULT hr = dir == OUTPUT ? stm->output_client->Start() : stm->input_client->Start();

Instead, every time we hit the device reconfigure case (that was causing trouble before) we test if OUTPUT is true (being the first member of an enum, it's 0) and null deref stm->input_client (unless it's a much-less-common input-only stream).

No idea how I missed this when I tested it.

Comment 6

[Matthew Gregan [:kinetik]]

Attachment: bug1263505_v1.patch

Tested more thoroughly to make sure I hit all the modified paths.  I'm pretty sure I missed this in the earlier patch because the OS/driver/hardware I tested on did the reconfigure through the event loop mechanism rather than the restart mechanism.

Comment 7

[Paul Adenot (:padenot)]

Pushed as part of https://hg.mozilla.org/integration/mozilla-inbound/rev/2f3a6b7cd4b3.

Comment 8

[Matthew Gregan [:kinetik]]

This signature is not showing up in recent crash stats; calling this fixed by bug 1263505.