Thanks for the feedback. It definitely looks like a deadlock from the crash report. I put together a demo using SIP.js and JSfiddle.
The caller: https://jsfiddle.net/Lk3h963n/7/ The target: https://jsfiddle.net/y31zh9qf/2/ When you press start on the caller a WebRTC video session will be established with the target. Pressing the hold button on the caller will initiate a renegotiation with the target. The target window will then hang. The remote video on the target will continue to render, but you will notice that the browser is inoperable. The crash only happens when FF is the target of a renegotiation with video, so I did not wire up the target buttons to do anything. The SIP.js code I am using can be found on this PR: https://github.com/onsip/SIP.js/pull/426. The code you would probably be most interested in is in the src/WebRTC/SessionDescriptionHandler.js, createOfferOrAnswer function. Line 249 is createAnswer and line 263 calls setLocalDescription. Let me know if I can assist further. Thanks, -Eric Green On Wednesday, August 23, 2017 at 3:51:38 PM UTC-4, Randell Jesup wrote: > On 8/23/2017 2:01 PM, Nils Ohlmeier wrote: > >> On Aug 23, 2017, at 08:34, Eric Green <[email protected]> wrote: > >> > >> I am working on implementing renegotiation into SIP.js, specifically > >> looking at hold/unhold via changing SDP attributes to sendonly. This is > >> working when Firefox negotiates audio only, or is the person triggering > >> the renegotiation. The problem starts when Firefox is doing a video call > >> and is the target of being put on hold. The browser will receive an SDP > >> offer with a=sendonly for both video and audio sections of the call. I > >> successfully apply this to the peer connection and the peer connection > >> changes to have-remote-offer state. I can successfully call createAnswer, > >> generate the RTCSessionDescription, but when I call setLocalDescription on > >> my peer connection with the answer from createAnswer, the browser will > >> lock up. > >> > >> This is one of my crash reports: > >> https://crash-stats.mozilla.com/report/index/9de4defb-5a39-4950-9f7f-c8e060170823 > >> > >> I could put together a simple demo to replicate this if needed. It is > >> happening in both the production version of Firefox and the Developer > >> build. Chrome is working successfully with the same javascript. > >> > >> Any thoughts on what I can do to make Firefox not crash on this? > > From looking at the crash report it would be super helpful if you could > > send me a way to reproduce this, e.g. point me to github page with code, or > > a link to web page for testing. > > Or open a bug report about it on https://bugzilla.mozilla.org > > <https://bugzilla.mozilla.org/> > > Which ever is easier for you. > > I agree with Nils -- an example would help a lot. I suspect there's > some sort deadlock on mCodecMutex -- apparently with thread 55, which is > calling WebrtcVideoConduit::SendVideoFrame(). OnVideoFrameConverted is > called with a lock on the pipeline listener mutex. Should be trivial to > debug with an example using 'rr' (and probably trivial in gdb) > > Randell Jesup, Mozilla _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
