MemoryMappedView leak

Open Beginner friendly
#133,744 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
operating-systems

Research direction

Start in src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Unix.cs, especially CreateView and the disposal path. Reproduce with empty views and verify that disposal successfully unmaps the OS-page mapping instead of calling munmap with a zero native length; add or update coverage for the empty-view case if the surrounding tests identify a suitable location.

Written by the indexing model from the issue text.

Description

area-System.IO

A few more findings from the same 64KiB-page machine, separate from the thunk and GC bitmap-accounting issues above:

  1. Empty memory-mapped views leak one OS-page mapping on Unix. CreateView maps one byte for an empty view but records a native length of zero. Disposal then calls munmap(address, 0), which fails. Reproduced against the locally built libraries: all 32 disposed empty views remained mapped. This isn't exclusive to 64KiB pages, but the leaked virtual mapping is 64KiB per view here, rather than 4KiB.

Originally posted by @EgorBo in #133675

Dominant language
C#
Stars
18.3k
Forks
5.6k
Avg merge
2d 19h
Merged PRs (30d)
589

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/runtime

All issues in dotnet/runtime

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.