Closed Bug 1263505 Opened 4 years ago Closed 4 years ago

crash in `anonymous namespace''::stream_start_one_side


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

Windows NT
Not set



Tracking Status
firefox48 --- affected


(Reporter: njn, Assigned: kinetik)



(Keywords: crash)

Crash Data


(1 file)

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).
kinetik, any ideas?
Flags: needinfo?(kinetik)
I think this is the same root cause as bug 1262345.
Flags: needinfo?(kinetik)
Should be fixed by bug 1262345, which landed in bug 1264594.
Assignee: nobody → kinetik
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 :(
Flags: needinfo?(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.
Flags: needinfo?(kinetik)
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.
Attachment #8742627 - Flags: review?(padenot)
Attachment #8742627 - Flags: review?(padenot) → review+
Depends on: 1265692
This signature is not showing up in recent crash stats; calling this fixed by bug 1263505.
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.