Closed Bug 1209280 Opened 9 years ago Closed 3 years ago

Intermittent test_peerConnection_twoVideoTracksInOneStream.html | PeerConnectionWrapper (pcRemote): legal ICE state transition from new to failed

Categories

(Core :: WebRTC, defect, P4)

Product:
Core
Component:
WebRTC
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1708677
Tracking Flags:
Tracking Status
firefox47 --- disabled
firefox48 --- disabled
Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: KWierso, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Android])

backlog: --- → webrtc/webaudio+
Rank: 38
Priority: -- → P3
I'm seeing this error on a try again.

Checking this log from November:
http://archive.mozilla.org/pub/mobile/tinderbox-builds/mozilla-inbound-android-api-11/1448244791/mozilla-inbound_ubuntu64_vm_armv7_large_test-mochitest-9-bm125-tests1-linux64-build40.txt.gz

It clearly shows that the ICE candidates trickle in waaayyy too late.
20:01:17     INFO -  410 INFO TEST-PASS | dom/media/tests/mochitest/test_peerConnection_twoVideoTracksInOneStream.html | iceConnectionState should not be undefined
20:01:17     INFO -  411 INFO PeerConnectionWrapper (pcRemote): oniceconnectionstatechange fired, new state is: failed
20:01:17     INFO -  412 INFO TEST-UNEXPECTED-FAIL | dom/media/tests/mochitest/test_peerConnection_twoVideoTracksInOneStream.html | PeerConnectionWrapper (pcRemote): legal ICE state transition from new to failed

20:01:17     INFO -      PeerConnectionWrapper.prototype.logIceConnectionState/this.ice_connection_callbacks.logIceStatus@dom/media/tests/mochitest/pc.js:1218:11
20:01:17     INFO -      PeerConnectionWrapper/this._pc.oniceconnectionstatechange/<@dom/media/tests/mochitest/pc.js:747:7
20:01:17     INFO -      PeerConnectionWrapper/this._pc.oniceconnectionstatechange@dom/media/tests/mochitest/pc.js:746:5
20:01:17     INFO -  413 INFO pcLocal: iceCandidate = {"candidate":"candidate:0 1 UDP 2122252543 10.0.2.15 56144 typ host","sdpMid":"sdparta_0","sdpMLineIndex":0}

Again we get bitten by the fact that mochitest log messages dumps hide the real time stamp of when the log message got created.
But the real question is: what is slowing down these tests so much, that ICE candidates take such a long time to show up?
See Also: → 1202046
#2 overall top failure on OrangeFactor. Can we skip this test on Android for now if nobody has time to look into this more?
Flags: needinfo?(drno)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)
> #2 overall top failure on OrangeFactor. Can we skip this test on Android for
> now if nobody has time to look into this more?

To be honest I spend recently quite some time looking into our PeerConnection tests on Android emulator. And my conclusion so far is that the emulator is simply too slow to handle our tests needs properly. Simple tests seem to just work, but as soon as we do something a little bit more fancy things get unstable. E.g. I have seen in log files a response to a request taking more then 6s. That is simply too slow for WebRTC to work properly.

So yeah go ahead and disable this test for now.

But I fear this turns only into a mass-disabling, until we have disabled (almost) everything.
Flags: needinfo?(drno)
status-firefox48: --- → disabled
Keywords: leave-open
Whiteboard: [test disabled on Android]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.