Bug 227233
| Summary: | [GTK][WPE] WebRTC tests failing since update of libwebrtc to M92 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Carlos Alberto Lopez Perez <clopez> |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | bugs-noreply, calvaris, pnormand, tsaunier, youennf |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=226494 | ||
Carlos Alberto Lopez Perez
On r278701 libwebrtc was updated to M92.
This caused a number of WebRTC related tests to start failing on GTK and WPE:
http/wpt/webrtc/third-party-frame-ice-candidate-filtering.html [ Failure ]
imported/w3c/web-platform-tests/webrtc-priority/RTCPeerConnection-ondatachannel.html [ Failure ]
inspector/page/overrideSetting-ICECandidateFilteringEnabled.html [ Timeout ]
webrtc/calling-peerconnection-once-closed.html [ Failure ]
webrtc/candidate-stats.html [ Failure ]
webrtc/closing-peerconnection.html [ Timeout ]
webrtc/datachannel/basic.html [ Timeout ]
webrtc/datachannel/binary.html [ Failure ]
webrtc/datachannel/bufferedAmount-afterClose.html [ Timeout ]
webrtc/datachannel/bufferedAmountLowThreshold-default.html [ Failure ]
webrtc/datachannel/bufferedAmountLowThreshold.html [ Failure ]
webrtc/datachannel/datachannel-gc.html [ Timeout ]
webrtc/datachannel/datachannel-page-cache.html [ Timeout ]
webrtc/datachannel/datachannel-page-cache-send.html [ Timeout ]
webrtc/datachannel/datachannel-stats.html [ Timeout ]
webrtc/datachannel/dtls10.html [ Failure ]
webrtc/datachannel/filter-ice-candidate.html [ Timeout ]
webrtc/datachannel/gather-candidates-networkprocess-crash.html [ Failure ]
webrtc/datachannel/getStats-no-prflx-remote-candidate.html [ Failure ]
webrtc/datachannel/multi-channel.html [ Failure ]
webrtc/filtering-ice-candidate-after-reload.html [ Timeout ]
webrtc/legacy-api.html [ Failure ]
webrtc/no-port-zero-in-upd-candidates.html [ Failure ]
However, I'm unable to reproduce this failures if I run the test locally one by one.
Only when running the whole test suite this failures are reproducible (like in the bots)
This may indicate some issue caused by a previous test run that leaves WTR on an inconsistent state or something like that.
The errors the tests give look related to failure to create the SDP data channel. Examples:
--- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webrtc/candidate-stats-expected.txt
+++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/webrtc/candidate-stats-actual.txt
@@ -1,3 +1,6 @@
+CONSOLE MESSAGE: Unhandled Promise Rejection: OperationError: Failed to set remote offer sdp: Failed to create data channel.
-PASS ICE candidate data channel stats
+Harness Error (FAIL), message = Failed to set remote offer sdp: Failed to create data channel.
+FAIL ICE candidate data channel stats promise_test: Unhandled rejection with value: "Test timed out"
+
--- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/webrtc-priority/RTCPeerConnection-ondatachannel-expected.txt
+++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/webrtc-priority/RTCPeerConnection-ondatachannel-actual.txt
@@ -1,4 +1,4 @@
FAIL In-band negotiated channel created on remote peer should match the same configuration as local peer assert_equals: expected "high" but got "low"
-PASS In-band negotiated channel created on remote peer should match the same (default) configuration as local peer
+FAIL In-band negotiated channel created on remote peer should match the same (default) configuration as local peer promise_test: Unhandled rejection with value: object "OperationError: Failed to set local offer sdp: Failed to create data channel."
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Carlos Alberto Lopez Perez
Expectations updated on r279080
Philippe Normand
Are you sure this wasn't fixed in https://trac.webkit.org/changeset/279065/webkit ?
Carlos Alberto Lopez Perez
(In reply to Philippe Normand from comment #2)
> Are you sure this wasn't fixed in
> https://trac.webkit.org/changeset/279065/webkit ?
You are right, r279065 fixed that.
I was looking at results from the bot previous to r279065 meanwhile testing on local build after r279065. That is why I wasn't able to reproduce it locally. My fault.
I removed the expectations on r279100
*** This bug has been marked as a duplicate of bug 227172 ***