You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
System.Net.Security.Tests failed with System.IO.IOException #52362
System.IO.IOException : Received an unexpected EOF or 0 bytes from the transport stream.
Stack trace
at System.Net.Security.SslStream.<FillHandshakeBufferAsync>g__InternalFillHandshakeBufferAsync|181_0[TIOAdapter](TIOAdapter adap, ValueTask`1 task, Int32 minSize) in /_/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.Implementation.cs:line 953
at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter) in /_/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.Implementation.cs:line 456
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm) in /_/src/libraries/System.Net.Security/src/System/Net/Security/SslStream.Implementation.cs:line 358
at System.Net.Security.Tests.ClientAsyncAuthenticateTest.ClientAsyncSslHelper(EncryptionPolicy encryptionPolicy, SslProtocols clientSslProtocols, SslProtocols serverSslProtocols, RemoteCertificateValidationCallback certificateCallback) in /_/src/libraries/System.Net.Security/tests/FunctionalTests/ClientAsyncAuthenticateTest.cs:line 155
at System.Net.Security.Tests.ClientAsyncAuthenticateTest.ClientAsyncAuthenticate_IndividualServerVsAllClientSupportedProtocols_Success(SslProtocols serverProtocol) in /_/src/libraries/System.Net.Security/tests/FunctionalTests/ClientAsyncAuthenticateTest.cs:line 102
--- End of stack trace from previous location ---
It is suspicious that the tests fail only with JitStress and all tests at once, also always together with test failures in #52361 -- perhaps some kind of environmental problem?
@BruceForstall could you help hypothesize why this only fails for jitstress? Is this a particularly slow form of jitstress?
Based on the table above, the test fails in many different types of jitstress. Some are slower (like zapdisable), but many should be much faster than normal, e.g., "no_tiered_compilation" which just says "turn on the JIT optimizer; don't allow tiering". Possibly some timing issue is exacerbated by the code running faster (due to the JIT optimizing the code)?
Note that one problem with most libraries tests is that the default run style is with tiered compilation enabled. That means that the test runs with no JIT optimization until it runs enough times to be "tiered up" / optimized. But most test code never reaches that level. However, the jitstress modes all disable tiering, forcing JIT optimization.
I think this duplicate of #52361. Depending on timing we can surface the server exception but if the client wins, we would see connection close as the server aborted and the exception is still to be processed.
Activity
VincentBu commentedon May 20, 2021
karelz commentedon May 20, 2021
Kusto -- methods to query:
Failures 3/18-9/2 (incl. PRs):
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
ServerAsyncAuthenticate_EachSupportedProtocol_Success
It is suspicious that the tests fail only with JitStress and all tests at once, also always together with test failures in #52361 -- perhaps some kind of environmental problem?
VincentBu commentedon Jun 16, 2021
VincentBu commentedon Jul 5, 2021
VincentBu commentedon Jul 12, 2021
VincentBu commentedon Jul 22, 2021
VincentBu commentedon Aug 2, 2021
VincentBu commentedon Aug 16, 2021
danmoseley commentedon Aug 16, 2021
@BruceForstall could you help hypothesize why this only fails for jitstress? Is this a particularly slow form of jitstress?
BruceForstall commentedon Aug 30, 2021
Based on the table above, the test fails in many different types of jitstress. Some are slower (like zapdisable), but many should be much faster than normal, e.g., "no_tiered_compilation" which just says "turn on the JIT optimizer; don't allow tiering". Possibly some timing issue is exacerbated by the code running faster (due to the JIT optimizing the code)?
Note that one problem with most libraries tests is that the default run style is with tiered compilation enabled. That means that the test runs with no JIT optimization until it runs enough times to be "tiered up" / optimized. But most test code never reaches that level. However, the jitstress modes all disable tiering, forcing JIT optimization.
Has anyone tried reproducing these locally?
VincentBu commentedon Sep 2, 2021
danmoseley commentedon Sep 2, 2021
Again coincident with #52361. @karelz probably one could dupe against the other.
karelz commentedon Sep 2, 2021
@danmoseley the exceptions are different, so keeping 2 different issues isn't bad. No need to dupe them.
wfurt commentedon Feb 8, 2022
I think this duplicate of #52361. Depending on timing we can surface the server exception but if the client wins, we would see connection close as the server aborted and the exception is still to be processed.