runtime: Disposing the FileSystemWatcher does not close associated file descriptors
Filed this against Mono, which uses corefx, but the problem also affects corefx.
https://github.com/mono/mono/issues/16709
Steps to Reproduce
Related problem - https://github.com/mono/mono/issues/15931
- Sample project - https://github.com/mrward/test-file-watcher-dispose - multi-target project that builds .NET 4.7.2 and .NET Core 2.1
- Build this project.
- From the command line run
dotnet bin/debug/netcoreapp2.1/FileWatcherDisposeTest.dll
- Run
lsof -p pid
. Process id is output from the console app. - See that the file watcher creates file descriptors for several directories.
- After 10 seconds the file watcher will be disposed.
- Run
lsof -p pid
again.
Current Behavior
lsof still lists the directories.
dotnet 3972 user 4r DIR 1,12 170 51740695 /Volumes/Drive/projects/tests/FileWatcherDisposeTest/FileWatcherDisposeTest/bin/Debug/net472
dotnet 3972 user 5r DIR 1,12 136 51740600 /Volumes/Drive/projects/tests/FileWatcherDisposeTest/FileWatcherDisposeTest/bin/Debug
dotnet 3972 user 6r DIR 1,12 102 51740599 /Volumes/Drive/projects/tests/FileWatcherDisposeTest/FileWatcherDisposeTest/bin
dotnet 3972 user 7r DIR 1,12 204 51740594 /Volumes/Drive/projects/tests/FileWatcherDisposeTest/FileWatcherDisposeTest
dotnet 3972 user 8r DIR 1,12 170 51740593 /Volumes/Drive/projects/tests/FileWatcherDisposeTest
dotnet 3972 user 9r DIR 1,12 6324 185300 /Volumes/Drive/projects/tests
dotnet 3972 user 10r DIR 1,12 2312 278 /Volumes/Drive/projects
dotnet 3972 user 11r DIR 1,12 646 2 /Volumes/Drive
dotnet 3972 user 12r DIR 1,4 160 420284 /Volumes
If you change the console project to run GC.Collect after the dispose does not fix the problem (this does work with Mono)
Expected Behavior
File watcher directories not listed by lsof.
Note that
On which platforms did you notice this
[x] macOS [ ] Linux [ ] Windows
Version Used:
dotnet --info .NET Core SDK (reflecting any global.json): Version: 3.0.100-preview9-014004 Commit: 8e7ef240a5
Runtime Environment: OS Name: Mac OS X OS Version: 10.14 OS Platform: Darwin RID: osx.10.14-x64 Base Path: /usr/local/share/dotnet/sdk/3.0.100-preview9-014004/
Host (useful for support): Version: 3.0.0-preview9-19423-09 Commit: 2be172345a
.NET Core SDKs installed: 2.1.701 [/usr/local/share/dotnet/sdk] 3.0.100-preview9-014004 [/usr/local/share/dotnet/sdk]
.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.0.0-preview9.19424.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.0.0-preview9-19423-09 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Stacktrace
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 28 (25 by maintainers)
Commits related to this issue
- Pull in fsw fix that fixes https://github.com/dotnet/corefx/issues/40888 Backport of: https://github.com/dotnet/corefx/pull/41013 — committed to steveisok/corefx by deleted user 5 years ago
- Pull in fsw fix that fixes https://github.com/dotnet/corefx/issues/40888 (#343) Backport of: https://github.com/dotnet/corefx/pull/41013 — committed to mono/corefx by steveisok 5 years ago
I put up PR with proposed fix. I’m not sure if possible but it would be great if anybody can give it try with VS. It does fix issue observed with provided repro.
Validated the corefx change against local corefx: https://gist.github.com/Therzok/37489ee04505d5e1c4a2d43ca85abed9
Definitely fixed here, the rest of the problems are in mono. Thank you @wfurt!
I’ll take a look. I drop it before as it look like @Therzok was digging into it.