Closed
Bug 1304269
Opened 6 years ago
Closed 6 years ago
Intermittent TEST-UNEXPECTED-TIMEOUT | dom/media/tests/mochitest/test_peerConnection_noTrickleOffer.html | application timed out after 330 seconds with no output
Categories
(Core :: WebRTC, defect, P3)
Core
WebRTC
Tracking
()
RESOLVED
DUPLICATE
of bug 1304519
mozilla52
Tracking | Status | |
---|---|---|
firefox50 | --- | unaffected |
firefox51 | --- | fixed |
firefox52 | --- | fixed |
People
(Reporter: intermittent-bug-filer, Assigned: drno)
References
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=3744805&repo=autoland https://archive.mozilla.org/pub/firefox/tinderbox-builds/autoland-win32-debug/1474380556/autoland_win7_ix-debug_test-mochitest-media-e10s-bm109-tests1-windows-build238.txt.gz
Updated•6 years ago
|
Rank: 35
Priority: -- → P3
Assignee | ||
Comment 1•6 years ago
|
||
Hmm really bizarre. ICE logging claims both PC's successfully connected within the first second of the test running. But the mochitest logging claims the ICE connection state never progressed from 'new' on one side and 'checking' on the second PC to any other state. I'm wondering if it would help to cleanup the waitForIceConnection() mess.
Comment hidden (mozreview-request) |
Comment 3•6 years ago
|
||
mozreview-review |
Comment on attachment 8793562 [details] Bug 1304269: lets promise ice from now on. https://reviewboard.mozilla.org/r/80286/#review79070 Seeing stuff that try barfed on, will re-review once that's cleared up.
Attachment #8793562 -
Flags: review?(docfaraday)
Comment hidden (mozreview-request) |
Comment 5•6 years ago
|
||
mozreview-review |
Comment on attachment 8793562 [details] Bug 1304269: lets promise ice from now on. https://reviewboard.mozilla.org/r/80286/#review79152 With nits. ::: dom/media/tests/mochitest/pc.js:767 (Diff revision 2) > + this.iceConnectedReject; > + this.iceConnected = new Promise((resolve, reject) => { > + this.iceConnectedResolve = resolve; > + this.iceConnectedReject = reject; > + }); > this.iceCheckingRestartExpected = false; We can get rid of this, right? ::: dom/media/tests/mochitest/pc.js:787 (Diff revision 2) > + if (iceState === "connected") { > + this.iceConnectedResolve(); > + } else if (iceState == "failed") { > + this.iceConnectedReject(); > + } Why === on one, but == on the other?
Attachment #8793562 -
Flags: review?(docfaraday) → review+
Assignee | ||
Comment 6•6 years ago
|
||
mozreview-review-reply |
Comment on attachment 8793562 [details] Bug 1304269: lets promise ice from now on. https://reviewboard.mozilla.org/r/80286/#review79152 > We can get rid of this, right? No we can't because it is still used to decide when it is okay to have the ICE connection state to go backwards.
Comment hidden (mozreview-request) |
Pushed by drno@ohlmeier.org: https://hg.mozilla.org/integration/autoland/rev/552477d11cd0 lets promise ice from now on. r=bwc
Comment 9•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/552477d11cd0
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox52:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Comment 10•6 years ago
|
||
What bug caused this?
Assignee: nobody → drno
status-firefox50:
--- → unaffected
status-firefox51:
--- → ?
Flags: needinfo?(drno)
Assignee | ||
Comment 11•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > What bug caused this? There is no specific bug I point at, just my observation from comment #1. It's mostly that the test code was written less then ideal back in the days before we had Promises. This is simply an attempt to handle waiting for ICE to connect in a way more clean way. My hope is that this could actually solve some intermittents around ICE failing to connect. But we should wait and see.
Flags: needinfo?(drno)
Comment 12•6 years ago
|
||
Yeah, I'm mainly asking to assess which other branches might be affected.
Assignee | ||
Comment 13•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #12) > Yeah, I'm mainly asking to assess which other branches might be affected. Sure. The not ideal test code has in our repo's since ages (way before 49). I was initially thinking to simply let this ride the train. But I can take an action item to look at how our ICE orange numbers are looking next week. And then we decide if it's worth uplifting.
Comment 14•6 years ago
|
||
bugherderuplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/57257bd35a87
Flags: in-testsuite+
Comment 15•6 years ago
|
||
Sorry to disappoint, this was bug 1304519.
Blocks: 1218576
Resolution: FIXED → DUPLICATE
Duplicate of bug: 1304519
You need to log in
before you can comment on or make changes to this bug.
Description
•