REGRESSION (r261277): [ Mac iOS ] webrtc/datachannel/gather-candidates-networkprocess-crash.html is a flaky timeout

• Component: New Bugs
• Status: RESOLVED FIXED

[Truitt Savell]

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.

[Radar WebKit Bug Importer]

<rdar://problem/63496692>

[Truitt Savell]

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

[Truitt Savell]

marking this test as a flaky timeout while it is investigated: https://trac.webkit.org/changeset/262010/webkit

[youenn fablet]

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.

[youenn fablet]

Created attachment 400195 [details]
Patch

[Maciej Stachowiak]

Was the patch meant to be flagged for review?

[EWS]

Committed r262183: <https://trac.webkit.org/changeset/262183>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 400195 [details].