Closed Bug 1304165 Opened 3 years ago Closed 3 years ago

Multiple renegotiations leads to crash in ActivateOrRemoveTransports

Categories

(Core :: WebRTC: Signaling, defect, P1)

49 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: mroberts, Assigned: bwc)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce:

The basic reproduction steps involve letting A and B send and receive audio and video over a single PeerConnection. Then B stops their video, renegotiates, adds a new video, and renegotiates again. Then A stops their video, renegotiates, adds a new video, and renegotiates again. This leads to a crash.

1. Setup two browser windows, A and B.
2. For each browser window,
2.1. Acquire a MediaStream containing both audio and video MediaStreamTracks using getUserMedia.
2.2. Construct a PeerConnection and add the MediaStream using addStream.
3. Negotiate (let A offer B, and let B answer).
4. Let B
4.1. Stop their video MediaStreamTrack.
4.2. Remove the stopped video MediaStreamTrack from their MediaStream with removeTrack.
5. Renegotiate (let B offer A, and let A answer)
6. Let B
6.1. Acquire a new MediaStream containing a single video MediaStreamTrack using getUserMedia.
6.2. Add the MediaStream using addStream.
7. Renegotiate (let B re-offer A, and let A answer).
8. Let A
8.1. Stop their video MediaStreamTrack.
8.2. Remove the stopped video MediaStreamTrack from their MediaStream with removeTrack.
9. Renegotiate (let A re-offer B, and let B answer).
10. Let A
10.1. Acquire a new MediaStream containing a single video MediaStreamTrack using getUserMedia.
10.2. Add the MediaStream using addStream.
11. Renegotiate (let A re-offer B, and let B answer).



Actual results:

Step 11 crashes, apparently in setLocalDescription with a EXC_BAD_ACCESS/KERN_INVALID_ADDRESS reason in ActivateOrRemoveTransports. My browser reported this in the crash logs a few times. For example, here:

https://crash-stats.mozilla.com/report/index/a02cc658-1f30-4768-a974-acebe2160920


Expected results:

Step 11 should succeed, with the end result that A and B continue to share audio and video (just like in Step 3, although with additional m=lines).
Status: NEW → UNCONFIRMED
Component: Untriaged → Audio/Video
Ever confirmed: false
Product: Firefox → Core
Rank: 15
Component: Audio/Video → WebRTC: Signaling
Priority: -- → P1
I am having no luck reproducing this crash on nightly. I'll try release next...
No luck on release either. Can you attach a test-case?
Flags: needinfo?(mroberts)
Flags: needinfo?(mroberts)
Hi Byron,

Sorry about that. I tried to reproduce with the instructions I shared and I was unable to as well. It turns out that my test application was actually triggering some recently added rollback code. I've extracted a test case (firefox-rollback-crash.hs) that can be run simply by pasting into the Firefox console.

It seems that rolling back after re-offering with { offerToReceiveAudio: true } and/or { offerToReceiveVideo: true } will trigger this crash.

Thanks,
Mark
Ahhhh, I was wondering whether rollback was somehow involved. Let me see what I can do.
Assignee: nobody → docfaraday
Attachment #8795782 - Flags: review?(drno)
Comment on attachment 8795782 [details]
Bug 1304165: More complete rollback of transport objects.

https://reviewboard.mozilla.org/r/81720/#review81070

LGTM
Attachment #8795782 - Flags: review?(drno) → review+
Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/54f4495e8855
More complete rollback of transport objects. r=drno
https://hg.mozilla.org/mozilla-central/rev/54f4495e8855
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.