On Linux, we attempt to re-use a socket for multiple connection attempts by "connecting" the socket to an invalid address between each "real" connect attempt. See PrimeForNextConnectAttempt. This does not work as intended. In the current implementation, the raw call to connect() cases any pending call to epoll_wait() to wake up and mark the socket as connected; any subsequent connect attempt on a non-blocking socket (or an Async connect attempt) then appears to succeed immediately, whether it did in fact or not.
This is causing some tests (e.g., System.Net.Sockets.Tests.DualMode.ConnectV4V6IPAddressListToV6Host_Success) to appear to succeed, even though the connection is never successfully established. Once dotnet/corefx#5472 is merged, this test will hang, as the non-blocking connect will now be blocking, and this bug will no longer mask the underlying issue.
I tried fixing this in the blocking case, by adding a call to PrimeForNextConnectAttempt after a blocking connect fails, and discovered that this also does not work. The subsequent connect attempt simply blocks until it times out.
If I disable this feature entirely, forcing Socket methods that connect to address lists to use multiple sockets instead, then the test passes.
On Linux, we attempt to re-use a socket for multiple connection attempts by "connecting" the socket to an invalid address between each "real" connect attempt. See PrimeForNextConnectAttempt. This does not work as intended. In the current implementation, the raw call to
connect()cases any pending call toepoll_wait()to wake up and mark the socket as connected; any subsequent connect attempt on a non-blocking socket (or an Async connect attempt) then appears to succeed immediately, whether it did in fact or not.This is causing some tests (e.g.,
System.Net.Sockets.Tests.DualMode.ConnectV4V6IPAddressListToV6Host_Success) to appear to succeed, even though the connection is never successfully established. Once dotnet/corefx#5472 is merged, this test will hang, as the non-blocking connect will now be blocking, and this bug will no longer mask the underlying issue.I tried fixing this in the blocking case, by adding a call to
PrimeForNextConnectAttemptafter a blockingconnectfails, and discovered that this also does not work. The subsequent connect attempt simply blocks until it times out.If I disable this feature entirely, forcing Socket methods that connect to address lists to use multiple sockets instead, then the test passes.