1181694 - crash in mozilla::MediaPipelineFactory::CreateMediaPipelineReceiving(mozilla::JsepTrackPair const&, mozilla::JsepTrack const&, unsigned int, mozilla::RefPtr<T>, mozilla::RefPtr<T>, nsAutoPtr<T>, mozilla::RefPtr<T> const&)

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Aaron Train [:aaronmt]]

This bug was filed from the Socorro interface and is 
report bp-fd8e2439-476d-4b90-8fbb-962fb2150705.
=============================================================

Comment 1

[Maire Reavy [:mreavy]]

Byron, Nils - This appears to be a null deref on Android.  (I'm not seeing this crash anywhere other than Android, but it doesn't mean it couldn't happen elsewhere.)  The volume of crashes on Android is the reason I made this a P1.  Can one of you take a deeper look, assess what's likely going on here (including how bad it likely is), and let me know (if you can) if this is a regression or if it's been in the code a while and just getting hit due to other changes?  Thanks.

Comment 2

[Eric Rescorla (:ekr)]

Taking an initial look, the following pointers appear to be in play:
mPCMedia:
https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/MediaPipelineFactory.cpp#437
This is a raw pointer, but the factory seems to be created in the same call stack.
Also, we use it to call a member function.

stream (returned from mPCMedia->GetRemoteStreamById())
https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/MediaPipelineFactory.cpp#436

mPC
https://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/MediaPipelineFactory.cpp#465
Also a raw pointer but should outlive the factory.

pipeline
The result of a new()

Comment 3

[Byron Campen [:bwc]]

This could definitely be caused by bug 1182289.

Comment 4

[Eric Rescorla (:ekr)]

(In reply to Byron Campen [:bwc] from comment #3)
> This could definitely be caused by bug 1182289.

That's good, because I don't see any likely candidates in this function.

Comment 5

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

Not related to bug 1182289; this goes back to at least Firefox 37 in crash-stats.  Crashes started in ~April, which may imply a specific site came online that triggers it.

Comment 6

[Maire Reavy [:mreavy]]

Nils -- Byron is pretty swamped, and I need someone to take the lead on investigating this.  Can I give this one to you?

Comment 7

[Nils Ohlmeier [:drno]]

(In reply to Randell Jesup [:jesup] from comment #5)
> Not related to bug 1182289; this goes back to at least Firefox 37 in
> crash-stats.  Crashes started in ~April, which may imply a specific site
> came online that triggers it.

I'm not able to find anything crash-stats with 37 in it, but 38.0.5. So that make this problem older then bug 1182289. I'll keep digging around...

Comment 8

[Nils Ohlmeier [:drno]]

Currently I'm suspecting that this might be caused by either:
a) some strange re-negotiation
b) or things are shutting down, while we are trying to a sLD() or sRD()

In some of the reports other threads show UpdateIceMediaStream_s() on the stack which is kind of scary, as it would mean two threads are at the same time in the SetSignalingState_m() function in different places. But these other thread dumps don't seem to make much sense.

Comment 9

[Nils Ohlmeier [:drno]]

Reminder to check crash stats some time in the future for >=40 as a sec bug fixed landed which looks like a plausible explanation for this crash.

Comment 10

[Nils Ohlmeier [:drno]]

So bug 1188590 landed in Beta on 07-29 and I don't see any crashes in 40.0b9 or 40.0 (which got build after that). So I think we can close this.