Closed Bug 863865 Opened 7 years ago Closed 7 years ago

WebRTC assertion failure: !mMasterSocket and crash [@mozilla::DataChannelConnection::~DataChannelConnection]

Categories

(Core :: WebRTC: Networking, defect, P2, critical)

defect

Tracking

()

RESOLVED FIXED
mozilla23
Tracking Status
firefox21 --- unaffected
firefox22 --- fixed
firefox23 --- fixed

People

(Reporter: posidron, Assigned: jesup)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, regression, Whiteboard: [webrtc][blocking-webrtc-][qa-])

Crash Data

Attachments

(4 files)

Attached file callstack
I do not have a testcase for this one but it happens periodically while trying to fuzz the SDP.

Before the assertion happens we can see the following in the log:

1980879232[612000009ac0]: Constructor DataChannelConnection=615000ca3300, listener=6120001780c8
1980879232[612000009ac0]: Setting number of SCTP streams to 16, was 10/2048
1980879232[612000009ac0]: Registered 615000ca3300 within the SCTP stack.
1980879232[612000009ac0]: Deleting DataChannelConnection 615000ca3300
Assertion failure: !mMasterSocket, at netwerk/sctp/datachannel/DataChannel.cpp:197

Tested with m-i changeset: 129149:9c124a12d219
Attached file NSPR_LOG
Attached file SDP
Priority: -- → P2
Whiteboard: [webrtc][blocking-webrtc-][webrtc-uplift]
Assignee: nobody → rjesup
Comment on attachment 739800 [details] [diff] [review]
Destroy() DataChannelConnection before releasing on errors in connecting Transport

We call Destroy() normally before releasing a DataChannelConnection since we need to grab a ref to send stuff to the STS thread to die; this is a (new due to the SDP-driven creation) bug where there's an intermediate failure case (ConnectViaTransport())
Attachment #739800 - Flags: review?(tuexen)
I have applied the patch to m-i tip and can not reproduce it anymore.
Crash Signature: [@ mozilla::DataChannelConnection::~DataChannelConnection] → [@ mozilla::DataChannelConnection::~DataChannelConnection()]
Comment on attachment 739800 [details] [diff] [review]
Destroy() DataChannelConnection before releasing on errors in connecting Transport

Review of attachment 739800 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. r+
Comment on attachment 739800 [details] [diff] [review]
Destroy() DataChannelConnection before releasing on errors in connecting Transport

r=tuexen
Attachment #739800 - Flags: review?(tuexen) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/0a4c39480a8c
OS: Mac OS X → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla23
https://hg.mozilla.org/mozilla-central/rev/0a4c39480a8c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [webrtc][blocking-webrtc-][webrtc-uplift] → [webrtc][blocking-webrtc-][webrtc-uplift][qa-]
Comment on attachment 739800 [details] [diff] [review]
Destroy() DataChannelConnection before releasing on errors in connecting Transport

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 856454 or bug 837035

User impact if declined: likely leaks an SCTP instance and socket in some odd timing/failure cases in opt builds; asserts in debug builds.

Testing completed (on m-c, etc.): on m-c

Risk to taking this patch (and alternatives if risky): Very low risk; calls existing cleanup routine in a failure path

String or IDL/UUID changes made by this patch: none
Attachment #739800 - Flags: approval-mozilla-aurora?
Attachment #739800 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/11ae3523b45e
Whiteboard: [webrtc][blocking-webrtc-][webrtc-uplift][qa-] → [webrtc][blocking-webrtc-][qa-]
You need to log in before you can comment on or make changes to this bug.