1304165 - Multiple renegotiations leads to crash in ActivateOrRemoveTransports

Status: RESOLVED FIXED

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

Description

[mroberts]

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).

Comment 1

[Byron Campen [:bwc]]

I am having no luck reproducing this crash on nightly. I'll try release next...

Comment 2

[Byron Campen [:bwc]]

No luck on release either. Can you attach a test-case?

Comment 3

[mroberts]

Attachment: firefox-rollback-crash.js

Comment 4

[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

Comment 5

[Byron Campen [:bwc]]

Ahhhh, I was wondering whether rollback was somehow involved. Let me see what I can do.

Comment 6

[Byron Campen [:bwc]]

Attachment: Bug 1304165: More complete rollback of transport objects.

Review commit: https://reviewboard.mozilla.org/r/81720/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/81720/

Comment 7

[Nils Ohlmeier [:drno]]

Comment on attachment 8795782 [details]
Bug 1304165: More complete rollback of transport objects.

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

LGTM

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/54f4495e8855
More complete rollback of transport objects. r=drno

Comment 9

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/54f4495e8855