Closed Bug 1263505 Opened 4 years ago Closed 4 years ago
crash in `anonymous namespace''::stream
_start _one _side
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?
I think this is the same root cause as bug 1262345.
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 :(
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.
Status: NEW → ASSIGNED
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+
Pushed as part of https://hg.mozilla.org/integration/mozilla-inbound/rev/2f3a6b7cd4b3.
This signature is not showing up in recent crash stats; calling this fixed by bug 1263505.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.