-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sporadic failure in file enumeration tests on Unix #54589
Comments
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsExamples - -
Some other callstack variations:
This began failing a few times a day on 6/15 which is coincident with #53669. Perhaps this will be fixed by #54483 @adamsitnik
|
Doh - that's a Windows change, still the date these started seems to be 2021-06-15 21:36:40.9310000 TestResults |
The issue seems to be very mysterious. Let's consider following example:
The source code: runtime/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs Lines 43 to 74 in 0416c34
What happens:
|
Brainstorming - are there other possible causes of EBADF? Eg., file is locked by someone using a different fd? |
A thought about the code @adamsitnik shared: if (Interop.Sys.FStat(handle, out status) != 0)
{
handle.Dispose();
throw Interop.GetExceptionForIoErrno(Interop.Sys.GetLastErrorInfo(), path); We should call I'll look at the issue closer in the coming week. |
The easiest explanation is that some other thread closed the file descriptor in the meantime. File descriptors are small numbers, and get reused heavily. This is a potential sequence of events: Thread A: calls close This failure pattern is consistent with what happened in #54615. The code called So I would be looking for a buggy code that is calling close twice. |
Oh of course. Hmm, interesting, as just about everything uses SafeXHandle, so it should be hard to call close() twice. More info from Kusto: first hit is 2021-06-15 21:36:40.9310000 (I assume it's UTC) after which it happens fairly often so I'd guess that's within a few hours of the problem being introduced. 9d771a2 went in at Tue Jun 15 20:59:58 2021 +0200. It happens in both release and debug. It only happens when running System.IO.Tests.* - which is consistent with the bug being in the tests, but not conclusive. It hits mostly tests that enumerate files, perhaps because there's a lot of fd's involved. The biggest hitter is System.IO.Tests.DirectoryInfo_EnumerateFiles_str_str but there are many others. It's evenly distributed across distros and macOS, but of course never Windows. Both x64 and Arm. |
Is this problematic? runtime/src/libraries/System.IO.FileSystem/tests/RandomAccess/Base.cs Lines 44 to 53 in 9d771a2
The SafeFileHandle takes ownership of the raw pipe handle. it is disposed and closes it, then the pipe is disposed and closes it again. This was introduce by above change. |
@danmoseley @tmds @jkotas big thanks for your help!! With #54660 I can't reproduce it anymore.
I've opened #54667 to address that |
Examples - -
Ubuntu Arm
osx 10.13 amd64
Some other callstack variations:
This began failing a few times a day on 6/15 which is coincident with #53669. Perhaps this will be fixed by #54483 @adamsitnik
The text was updated successfully, but these errors were encountered: