MemoryMappedFile (Windows): failed MEM_COMMIT is ignored, accessor over reserved memory crashes the process
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- csharp
- Domain
- backend, operating-systems
Research direction
Read src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Windows.cs, especially lines 62–70, where VirtualAlloc commits pages for delayed allocation. Check how nearby code reports native allocation failures and disposes the view. Done means a failed commit makes view creation throw instead of returning an accessor that can crash on write.
Written by the indexing model from the issue text.
Description
Description
MemoryMappedView.CreateView calls Interop.VirtualAlloc(..., MEM_COMMIT, ...) for DelayAllocatePages views but discards its return value. The following failure check tests viewHandle.IsInvalid (the already-valid map view handle) instead, so a failed commit is treated as success and the view is published over MEM_RESERVE pages.
Repro
Plain safe C#. The view is larger than the system commit limit.
using System.IO.MemoryMappedFiles;
using var mmf = MemoryMappedFile.CreateNew(null, 1L << 42, MemoryMappedFileAccess.ReadWrite,
MemoryMappedFileOptions.DelayAllocatePages, HandleInheritability.None);
using var acc = mmf.CreateViewAccessor(0, 1L << 40);
Console.WriteLine("accessor created, capacity=" + acc.Capacity);
acc.Write(0, (byte)1);
Console.WriteLine("write succeeded");
Actual behavior
net11.0 RC2, win-x64 (64 GB RAM, commit limit ~103 GB). CreateViewAccessor succeeds, then an in-range write is a fatal AccessViolationException:
accessor created, capacity=1099511627776
Fatal error.
(1L << 36 = 64 GB views succeed on this machine, so it only reproduces above the commit limit.)
Expected behavior
CreateViewAccessor / CreateViewStream throws (e.g. IOException / Win32Exception for the commit failure). Safe accessor APIs never fault.
Notes
src/libraries/System.IO.MemoryMappedFiles/src/System/IO/MemoryMappedFiles/MemoryMappedView.Windows.cs:62-70.- Fix: capture the
VirtualAllocresult, and on failure dispose the view and throw with the last error.
- Dominant language
- C#
- Stars
- 18.4k
- Forks
- 5.8k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 644
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/runtime
-
area-System.ComponentModel untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
dotnet/runtime#136608 · 2 comments ·
Maintainers usually reply within 1 day
-
area-System.IO untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
dotnet/runtime#136577 · 1 comment ·
Maintainers usually reply within 1 day
-
[mono] Native memory leak on the first invoke of every open-instance delegate to a virtual methodOpenarea-VM-meta-mono untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
dotnet/runtime#136284 · 6 reactions ·
Maintainers usually reply within 1 day
-
Several MemoryExtensions.LastIndexOfAnyExcept overloads incorrectly document "first occurrence"Possibly taken @ehsan-raoufi claimed this 5 days ago. Openarea-System.Memory untriaged
Difficulty 1/5 Under an hour Newbie friendliness 83/100
dotnet/runtime#136282 · 1 comment ·
Maintainers usually reply within 1 day
-
MemoryExtensions.LastIndexOf ignores a custom comparer for bitwise-equatable element typesPossibly taken @aw0lid claimed this 6 days ago. Openarea-System.Runtime untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
dotnet/runtime#136281 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug 優先: 低
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
.NET area: storage bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Larson-Logan/medal-sync#61 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day