Skip to content

Fix LinuxUserland::read_maps to handle large /proc/self/maps output - #1407

Closed
dywongcloud wants to merge 2 commits into
microsoft:mainfrom
dywongcloud:fix/issue-1328
Closed

dywongcloud wants to merge 2 commits into
microsoft:mainfrom
dywongcloud:fix/issue-1328

Conversation

@dywongcloud

@dywongcloud dywongcloud commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

As described in [issue #1328](#1328), read_maps() could panic when /proc/self/maps exceeded its fixed 8 KiB buffer, sometimes triggered by worker threads starting during the read.

Read into a growable buffer until EOF, retaining partial data if allocation fails. Parse the raw bytes so non-UTF-8 pathnames do not prevent parsing. Add a regression test with thousands of mappings that exceed the old limit.

read_maps() read /proc/self/maps into a fixed 8 KiB stack buffer and
asserted the read fit, panicking with "buffer too small" once the
process had enough mappings to exceed that size. This was hit in CI as
a timing-dependent race: the broker starting worker threads while
read_maps() was capturing the process's mappings could push the file
past 8 KiB.

Replace the fixed-size read with an EOF-driven loop into a growable
buffer, backing off gracefully (keeping whatever was read so far)
if growing the buffer fails, consistent with this function's existing
best-effort contract (it already returns nothing if the file can't be
opened, and mappings created during/after the read are still not
guaranteed to be captured). Parsing now works directly off the raw
bytes instead of requiring the whole file to be valid UTF-8, since a
mapped file's pathname field isn't guaranteed to be one.

Adds a regression test that creates thousands of small mappings to
push /proc/self/maps past the old 8 KiB limit and calls read_maps()
directly, verifying it no longer panics.

Fixes microsoft#1328
@dywongcloud

dywongcloud commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor Author

@CvvT

Copy link
Copy Markdown
Contributor

Thanks for the contribution! However, I'm working on refactoring/redesigning the memory management interfaces and this PR would become unnecessary then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants