851997 - Entire browser hangs after calling createDataChannel() before .onconnection() has fired

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Chris Ball]

Attachment: JS source

Steps to reproduce using Nightly (these are complicated, but they reproduce 100% of the time when followed correctly):

1. Unzip the attached .zip
2. Load "webrtc-sender.html" in one tab and "webrtc-receiver.html" in another
3. Open the JS console on both tabs.
4. In webrtc-sender.html's console, type "pc1.localDescription" and hit return
5. Right click on the "offer" output and copy to clipboard.
6. In webrtc-recipient.html's console, type "handleOfferFromPC1(<paste>"
7. Trim the timestamp and one "(" from the front of the paste
8. Hit return to execute

You should see:

"Got remote stream / Attaching media stream / Got answer"

9. Still in webrtc-recipient's console, type "pc2.localDescription" and hit return
10. Right click on the "answer" output and copy to clipboard.
11. Back in webrtc-sender's console, type "handleAnswerFromPC2(<paste>"
12. Trim the timestamp and one "(" from the front of the paste
13. Hit return to execute

You should see:

"addstream / calling connectDataConnection"

At this point, both sides of the connection have called connectDataConnection() with opposing ports, so there should be a DataConnection active.  But the two .onconnection() callbacks haven't fired.  I don't know why; I'm very interested in hearing where the bug is!

Regardless, if at this point you run the following in webrtc-sender's console:

dc1 = pc1.createDataChannel('test', {reliable:false});

You'll get a hard browser hang; backtrace attached.

The hang reproduces whether or not reliable:false is provided, and no matter whether pc1 or pc2 calls createDataChannel().

Comment 1

[Chris Ball]

Attachment: gdb backtrace

Comment 2

[Chris Ball]

Oops, s/webrtc-recipient/webrtc-receiver/g in the instructions above.

Comment 3

[Chris Ball]

I tried reproducing on Windows XP with Nightly, it causes a full browser crash (instead of a full browser hang) there.

Comment 4

[Chris Ball]

Windows XP crash report: https://crash-stats.mozilla.com/report/index/bp-7d8788af-5969-4a28-8988-d39c62130318

Comment 5

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

This is all getting totally reworked as part of bug 855623, so whatever the cause here it's likely to be moot shortly.

Comment 6

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

Should be fixed by checkin for bug 855623

Comment 7

[Chris Ball]

Thanks, confirmed fixed!