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

  1. Sample project - https://github.com/mrward/test-file-watcher-dispose - multi-target project that builds .NET 4.7.2 and .NET Core 2.1
  2. Build this project.
  3. From the command line run dotnet bin/debug/netcoreapp2.1/FileWatcherDisposeTest.dll
  4. Run lsof -p pid. Process id is output from the console app.
  5. See that the file watcher creates file descriptors for several directories.
  6. After 10 seconds the file watcher will be disposed.
  7. 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

Most upvoted comments

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.