runtime: Assertion failure 0 <= fd && fd < sysconf(_SC_OPEN_MAX) in System.Net.Mail.Functional.Tests
Description
System.Net.Mail.Functional.Tests are failing with this assert in CI:
----- start Fri 22 Jul 2022 12:11:04 PM UTC =============== To repro directly: =====================================================
pushd .
/root/helix/work/correlation/dotnet exec --runtimeconfig System.Net.Mail.Functional.Tests.runtimeconfig.json --depsfile System.Net.Mail.Functional.Tests.deps.json xunit.console.dll System.Net.Mail.Functional.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing
popd
===========================================================================================================
/root/helix/work/workitem/e /root/helix/work/workitem/e
Discovering: System.Net.Mail.Functional.Tests (method display = ClassAndMethod, method display options = None)
Discovered: System.Net.Mail.Functional.Tests (found 154 of 156 test cases)
Starting: System.Net.Mail.Functional.Tests (parallel test collections = on, max threads = 2)
System.Net.Mail.Tests.SmtpClientTest.TestGssapiAuthentication [SKIP]
Condition(s) not met: "IsNtlmInstalled"
dotnet: /__w/1/s/src/native/libs/Common/pal_utilities.h:86: int ToFileDescriptor(intptr_t): Assertion `0 <= fd && fd < sysconf(_SC_OPEN_MAX)' failed.
Reproduction Steps
Example CI build: https://dev.azure.com/dnceng/public/_build/results?buildId=1897299&view=ms.vss-test-web.build-test-results-tab
Expected behavior
Test doesn’t fail in CI
Actual behavior
Test does fail in CI, see description.
Regression?
Unknown
Known Workarounds
Unknown
Configuration
Linux Debug x64 Mono Interpreter
Other information
No response
{ "ErrorMessage":"0 <= fd && fd < sysconf(_SC_OPEN_MAX)" }
Report
| Build | Definition | Test | Pull Request |
|---|---|---|---|
| 47765 | dotnet/runtime | System.Net.Mail.Functional.Tests.WorkItemExecution | dotnet/runtime#76871 |
| 37711 | dotnet/runtime | System.Net.Mail.Functional.Tests.WorkItemExecution | |
| 36085 | dotnet/runtime | System.Net.Mail.Functional.Tests.WorkItemExecution | |
| 33387 | dotnet/runtime | System.Net.Mail.Functional.Tests.WorkItemExecution |
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 4 |
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 35 (35 by maintainers)
I haven’t looked at the code, but I think there probably is such a path. SmptClient SendAsync establishes the connection, and connect calls ReplaceHandle on Unix to try multiple IP addresses.
The fix in https://github.com/dotnet/runtime/pull/70046 (previously mentioned by @wfurt) was about making SendAsync keep using an open connection, see https://github.com/dotnet/runtime/issues/49340#issuecomment-1141867717. So that may have triggered the issue.
It’s definitely possible we seeing a race between connect replacing the handle, and SmtpClient Abort observing this half-initialized handle.
Ah, I didn’t realize it’s multithreaded.
@wfurt I found out that you need to specifically filter for 134 and 139 exit codes to get true process crashes
I think it was the same test we disabled in #73452 (SendMailAsync_CanBeCanceled_CancellationToken)
Aside from some authentication changes, #70046 would be biggest suspect. It may not be root cause as the assert is in Sockets. I tried to reproduce it (main on Linux) but I did not get hit. We can probably look at some of the Linux/Windows core files to see what particular tests are running.
Very often, 98 hits in the last 14 days. Curiously, none of these are on main