Bug 212218 - REGRESSION (r261277): [ Mac iOS ] webrtc/datachannel/gather-candidates-networkprocess-crash.html is a flaky timeout
Summary: REGRESSION (r261277): [ Mac iOS ] webrtc/datachannel/gather-candidates-networ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-21 09:31 PDT by Truitt Savell
Modified: 2020-05-25 05:17 PDT (History)
5 users (show)

See Also:


Attachments
Patch (2.45 KB, patch)
2020-05-25 05:16 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Truitt Savell 2020-05-21 09:31:14 PDT
webrtc/datachannel/gather-candidates-networkprocess-crash.html

This test began timing out recently

History:
https://results.webkit.org/?suite=layout-tests&test=webrtc%2Fdatachannel%2Fgather-candidates-networkprocess-crash.html

I am able to reproduce the timeout with command:
run-webkit-tests --iterations 2000 --exit-after-n-failures 1 --exit-after-n-crashes-or-timeouts 1 --debug-rwt-logging --no-retry --force --no-build -f webrtc/datachannel/gather-candidates-networkprocess-crash.html

I am working to bisect this now.
Comment 1 Radar WebKit Bug Importer 2020-05-21 09:31:31 PDT
<rdar://problem/63496692>
Comment 2 Truitt Savell 2020-05-21 09:51:31 PDT
it looks like this was caused by the changes in https://trac.webkit.org/changeset/261277/webkit

I am able to reproduce on 261277 but not 261276
Comment 3 Truitt Savell 2020-05-21 10:01:16 PDT
marking this test as a flaky timeout while it is investigated: https://trac.webkit.org/changeset/262010/webkit
Comment 4 youenn fablet 2020-05-25 02:45:46 PDT
There is a slight moment in time where the socket factory has no connection due to a crash in network process.
In that case, the factory will ask for a new connection to network process and in the meantime will fail the socket creations.
We do not want to do callOnMainThreadAndWait as this might deadlock the web process in that case.

The current approach is fine as is as the socket could have been created a few seconds before and would have been closed by network process crash.
I'll update the test to make it more robust.
Comment 5 youenn fablet 2020-05-25 05:16:39 PDT
Created attachment 400195 [details]
Patch