1182098 - crash in MediaStreamGraphImpl::ApplyStreamUpdate()

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: MediaStreamGraph, defect, P3)

Description

[Martijn Wargers (dead)]

I'm still crashing with the testcase from bug 1155965: https://bugzilla.mozilla.org/attachment.cgi?id=8594319

You need to have the specialpowers extension installed to see the crash:
http://people.mozilla.org/~mwargers/extensions/specialpowers/specialpowers.htm

I think it happens after having it let run for a while and then close or reload the page.

This bug was filed from the Socorro interface and is 
report bp-1b3fa14a-474d-4e14-b436-278632150709.
=============================================================
 0 	XUL 	mozilla::MediaPipelineTransmit::MediaPipelineTransmit(std::string const&, nsCOMPtr<nsIEventTarget>, nsCOMPtr<nsIEventTarget>, mozilla::DOMMediaStream*, std::string const&, int, bool, mozilla::RefPtr<mozilla::MediaSessionConduit>, mozilla::RefPtr<mozilla::TransportFlow>, mozilla::RefPtr<mozilla::TransportFlow>, nsAutoPtr<mozilla::MediaPipelineFilter>) 	dom/media/DOMMediaStream.h
1 	XUL 	mozilla::MediaPipelineFactory::CreateMediaPipelineSending(mozilla::JsepTrackPair const&, mozilla::JsepTrack const&, unsigned long, mozilla::RefPtr<mozilla::TransportFlow>, mozilla::RefPtr<mozilla::TransportFlow>, nsAutoPtr<mozilla::MediaPipelineFilter>, mozilla::RefPtr<mozilla::MediaSessionConduit> const&) 	media/webrtc/signaling/src/mediapipeline/MediaPipeline.h
2 	XUL 	mozilla::MediaPipelineFactory::CreateOrUpdateMediaPipeline(mozilla::JsepTrackPair const&, mozilla::JsepTrack const&) 	media/webrtc/signaling/src/peerconnection/MediaPipelineFactory.cpp
3 	XUL 	mozilla::PeerConnectionMedia::UpdateMediaPipelines(mozilla::JsepSession const&) 	media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp
4 	XUL 	mozilla::PeerConnectionImpl::SetSignalingState_m(mozilla::dom::PCImplSignalingState, bool) 	media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
5 	XUL 	mozilla::PeerConnectionImpl::SetRemoteDescription(int, char const*) 	media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp
6 	XUL 	mozilla::dom::PeerConnectionImplBinding::setRemoteDescription 	media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.h
7 	XUL 	mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*) 	dom/bindings/BindingUtils.cpp
etc..

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Martijn, can you try it in beta?  thanks

Comment 2

[Byron Campen [:bwc]]

Not seeing anything obvious that would cause this. I'll have to make some time to repro and debug.

Comment 3

[Byron Campen [:bwc]]

Attachment: Try to remove the dependency on SpecialPowers for the test-case.

Comment 4

[Byron Campen [:bwc]]

Ok, attached testcase can be used without specialpowers provided you are a fast clicker and can manage to hit the "Always Allow" on the GUM dialog.

Comment 5

[Byron Campen [:bwc]]

I've hit the following assertion a couple of times now. I'll try a non-debug build in a bit.

Assertion failure: state_ == NR_CONNECTED || state_ == NR_CLOSING, at ../../../../media/mtransport/nr_socket_prsock.cpp:1118

Comment 6

[Byron Campen [:bwc]]

Hmm. Can't get non-debug ASAN to build. Let me try removing that assertion.

Comment 7

[Byron Campen [:bwc]]

I'm having no luck reproducing that particular crash, either using ASAN on linux, or a release build of nightly on OS X. I'll keep trying.

Comment 8

[Byron Campen [:bwc]]

Ok, I got the same stack on a nightly build by opening the test in a non-e10s window. I also tried on release, and got a stack that seems similar but happens slightly earlier, down in some MSG code.

https://crash-stats.mozilla.com/report/index/7d412a19-d41c-4a09-b1d3-3c18f2150709

Comment 9

[Martijn Wargers (dead)]

(In reply to Randell Jesup [:jesup] from comment #1)
> Martijn, can you try it in beta?  thanks

Yes, also crashes: https://crash-stats.mozilla.com/report/index/862d9fc3-8361-44a1-a270-ae4f02150709
But that's basically bug 1155965.

Comment 10

[Byron Campen [:bwc]]

Ok, I believe this bug is fixed on m-c now. Give it another whirl and let me know how it goes.

Comment 11

[Martijn Wargers (dead)]

I'm still seeing it in current m-c: https://crash-stats.mozilla.com/report/index/b560f6ef-8806-4208-94d0-7b6a42150727
Although it took me a while to get this crash.

Comment 12

[Martijn Wargers (dead)]

Or do you mean this would be fixed by bug 1182289? In that case, I would need to test in tomorrow's Nightly build, right?

Comment 13

[Byron Campen [:bwc]]

> Or do you mean this would be fixed by bug 1182289? In that case, I would
> need to test in tomorrow's Nightly build, right?

   Yes, in order to test today you'd need build locally, or go grab a build artifact from here:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=27ae736ef960

Comment 14

[Martijn Wargers (dead)]

Still crashin on 42.0a1 (2015-07-28), but with a different stacktrace:
https://crash-stats.mozilla.com/report/index/b904e2d7-1a1e-4431-a73b-f32d52150728
0 	XUL 	mozilla::MediaStreamGraphImpl::ApplyStreamUpdate(mozilla::StreamUpdate*) 	dom/media/MediaStreamGraph.cpp
1 	XUL 	mozilla::MediaStreamGraphImpl::RunInStableState(bool) 	dom/media/MediaStreamGraph.cpp
2 	XUL 	mozilla::(anonymous namespace)::MediaStreamGraphStableStateRunnable::Run() 	dom/media/MediaStreamGraph.cpp
3 	XUL 	nsBaseAppShell::RunSyncSectionsInternal(bool, unsigned int) 	widget/nsBaseAppShell.cpp
4 	XUL 	nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool, unsigned int) 	widget/nsBaseAppShell.h
5 	XUL 	nsAppShell::OnProcessNextEvent(nsIThreadInternal*, bool, unsigned int) 	widget/cocoa/nsAppShell.mm
6 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
7 	XUL 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
8 	XUL 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
9 	XUL 	mozilla::CryptoTask::Run() 	security/manager/ssl/CryptoTask.cpp
10 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp

Comment 15

[Maire Reavy [:mreavy]]

The very different signature makes me think the original bug is resolved here.  If there's still a problem, it's a different one.

Comment 16

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats.  Other resolutions may be appropriate for other reasons.

(Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes.  The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)

Comment 20

[Andrei Purice]

Marking this as Resolved > Worksforme since the test case doesn't crash any of the latest versions of Firefox Nightly 91.0a1 (2021-06-18), Beta 90.0b9 or Release 89.0.1 on MacOS 11.4.