Skip to content

Fix FileSystemWatcher state cleanup on dispose/finalization on Windows #116830

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

Merged
merged 4 commits into from
Jun 22, 2025

Conversation

stephentoub
Copy link
Member

@stephentoub stephentoub commented Jun 19, 2025

When the FSW is disposed or finalized while it's in use, on Windows the implementation disposes of the directory handle as a mechanism to stop the monitoring. If by that point the state object's weak reference to the FSW has been cleared out (which it always will have been in the case of finalization), the state object's relevant members are not disposed, leaking several objects. This fixes that to ensure the state is cleaned up, by cleaning it up when the callback is unable to get the FSW instance.

This also addresses concerns over long-pinned managed buffers by switching to using a native buffer. Today the buffer is allocated and then immediately pinned, due to being passed immediately to the OS via a P/Invoke, and all writes to that buffer happen in unmanaged code. All reading also is already happening via a bounds-checked span. So instead of allocating and pinning a managed array, just allocate a native buffer, wrapped in a SafeHandle.

Fixes #86146
Fixes #116614
Fixes #116768

When the FSW is disposed or finalized while it's in use, on Windows the implementation disposes of the directory handle as a mechanism to stop the monitoring. If by that point the state object's weak reference to the FSW has been cleared out (which it always will have been in the case of finalization), the state object's relevant members are not disposed, leaking several objects. This fixes that to ensure the state is cleaned up, by cleaning it up when the callback is unable to get the FSW instance.

This also addresses concerns over long-pinned managed buffers by switching to using a native buffer. Today the buffer is allocated and then immediately pinned, due to being passed immediately to the OS via a P/Invoke, and all writes to that buffer happen in unmanaged code. All reading also is already happening via a bounds-checked span. So instead of allocating and pinning a managed array, just allocate a native buffer, wrapped in a SafeHandle.
@Copilot Copilot AI review requested due to automatic review settings June 19, 2025 18:32
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a resource leak in FileSystemWatcher on Windows by ensuring proper cleanup of the state object during dispose/finalization and by switching from a managed buffer (which is immediately pinned) to a native buffer wrapped in a SafeHandle. Key changes include:

  • Removal of managed array buffer allocation in the Windows implementation.
  • Introduction of native buffer allocation via SafeNativeMemoryHandle along with appropriate disposal in AsyncReadState.
  • Updates to the interop signature and Linux implementation to maintain consistency.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File Description
src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.cs Removed the old AllocateBuffer method that used a managed byte array.
src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.Win32.cs Changed buffer allocation to use SafeNativeMemoryHandle, updated resource disposal in the overlapped callback, and ensured state cleanup if the watcher has been garbage collected.
src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.Linux.cs Added a managed AllocateBuffer method for the Linux implementation.
src/libraries/Common/src/Interop/Windows/Kernel32/Interop.ReadDirectoryChangesW.cs Modified the interop definition to accept a SafeBuffer rather than a byte array.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@stephentoub stephentoub merged commit a87cf1b into dotnet:main Jun 22, 2025
80 of 86 checks passed
@stephentoub stephentoub deleted the fswleak branch June 22, 2025 00:39
@MaceWindu
Copy link

will it fix #86146?

@stephentoub
Copy link
Member Author

will it fix #86146?

It should, yes, at least in terms of the resources getting cleaned up eventually by finalization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants