Closed Bug 1345791 Opened 8 years ago Closed 8 years ago

Crash in mozilla::NrIceCtx::SetConnectionState

Categories

(Core :: WebRTC: Networking, defect, P3)

52 Branch
Unspecified
Windows 7
defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- fixed

People

(Reporter: calixte, Assigned: drno)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, Whiteboard: [clouseau])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is report bp-5d1f4743-d8d5-402d-9bdd-3605c2170308. ============================================================= There are 4 crashes in nightly 55 with buildid 20170308030207. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1342523. [1] https://hg.mozilla.org/mozilla-central/rev?node=d99df97e4115adbc20a76be02407b74a508565bf
Flags: needinfo?(docfaraday)
Rank: 10
Priority: -- → P1
We're hitting an unexpected assertion here, which suggests there is a corner case that we did not anticipate happening, but it isn't scary or common. I suspect that what is happening here is a stream succeeds (ICE), and while we are waiting for the rest of the streams to succeed, consent times out. If this is true, it probably makes sense to treat this as a failure. What do you think Nils?
Severity: critical → normal
Rank: 10 → 30
Flags: needinfo?(docfaraday) → needinfo?(drno)
Priority: P1 → P3
Either Consent timeouts during call setup or Necko telling us the network went offline while trying to establish the call. Either way I would prefer to not include this "edge" case into the failure category. So either just ignore it, or create a new telemetry probe just for this case. The latter might actually be helpful as time boxed thing (e.g. up to version 56 or something like that) to get an idea how common this "edge" case is.
Flags: needinfo?(drno)
I hit this on meet.jit.si, it was during call setup, when switched out to another tab (network state didn't change).
@bwc: the stack trace actually shows that we overlooked that the even though the switch checking->disconnected should not happen, the legit switch which trips over this is connected->disconnected. We could try differentiate between the two, but I'm not sure what we would gain by doing so.
Assignee: nobody → drno
Attachment #8852678 - Flags: review?(docfaraday) → review+
Pushed by drno@ohlmeier.org: https://hg.mozilla.org/integration/autoland/rev/0c2ca5a4f0a6 ICE disconnect state is not a crash. r=bwc
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: