Closed
Bug 1345791
Opened 8 years ago
Closed 8 years ago
Crash in mozilla::NrIceCtx::SetConnectionState
Categories
(Core :: WebRTC: Networking, defect, P3)
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)
Updated•8 years ago
|
Rank: 10
Priority: -- → P1
Comment 1•8 years ago
|
||
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
Assignee | ||
Comment 2•8 years ago
|
||
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)
Comment 3•8 years ago
|
||
I hit this on meet.jit.si, it was during call setup, when switched out to another tab (network state didn't change).
Comment hidden (mozreview-request) |
Assignee | ||
Comment 5•8 years ago
|
||
@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
Comment 6•8 years ago
|
||
mozreview-review |
Comment on attachment 8852678 [details]
Bug 1345791: ICE disconnect state is not a crash.
https://reviewboard.mozilla.org/r/124862/#review127398
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
Comment 8•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Updated•8 years ago
|
status-firefox52:
--- → unaffected
status-firefox53:
--- → unaffected
status-firefox54:
--- → unaffected
status-firefox-esr52:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•