Repository navigation
Unreadable is the absence of an answer, not a claim - #184
Merged
Merged
Conversation
The doc comments this state landed with said it is "memory the walk could not read, and which the target *has*". That is true of the cases the memory manager confirms committed and false of every case where no commitment query could be made at all — a kernel walk, a dump recording no memory information, a query that failed — which is precisely the half `committed_run`'s `None` arm exists for. `Uncommitted` carries a positive answer; `Unreadable` carries the absence of one. Saying otherwise turns *we could not tell* into a fact about the target, which is the one thing this walker is built not to do. Corrected at both definition sites and in `docs/unknown-not-absent.md`, whose new section is where the distinction is stated. Prose only; no behaviour changes and 435 tests pass unchanged. Raised by review on glslang/windbg-mcp#382. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUhLUt9rB6zd42Y25btB3h
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
glslang
added a commit
to glslang/windbg-mcp
that referenced
this pull request
Sep 24, 2026
Review on this PR found the prose describing `unreadable` as "memory the process has". That is true of the cases the memory manager confirms committed and false of every case where no commitment query could be made at all — a kernel walk, a dump recording no memory information, a query that failed — which is precisely what the conservative default is for. `uncommitted` carries a positive answer; `unreadable` carries the absence of one, and saying otherwise turns "we could not tell" into a fact about the target. Also re-derives the full-surface figure in `docs/tool-surface.md`'s opening sentence, which said 94,921 B dated 2026-09-20 while the table two lines below it said 94,957 — that sentence is prose, so the test that checks the tables never looked at it, and it now says so. Fixed at the dbgscope definition sites too, in glslang/dbgscope#184. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUhLUt9rB6zd42Y25btB3h
glslang
added a commit
to glslang/windbg-mcp
that referenced
this pull request
Sep 24, 2026
Review on this PR found the prose describing `unreadable` as "memory the process has". That is true of the cases the memory manager confirms committed and false of every case where no commitment query could be made at all — a kernel walk, a dump recording no memory information, a query that failed — which is precisely what the conservative default is for. `uncommitted` carries a positive answer; `unreadable` carries the absence of one, and saying otherwise turns "we could not tell" into a fact about the target. Also re-derives the full-surface figure in `docs/tool-surface.md`'s opening sentence, which said 94,921 B dated 2026-09-20 while the table two lines below it said 94,957 — that sentence is prose, so the test that checks the tables never looked at it, and it now says so. Fixed at the dbgscope definition sites too, in glslang/dbgscope#184. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUhLUt9rB6zd42Y25btB3h
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prose only, following review on glslang/windbg-mcp#382. No behaviour changes; 435 tests pass unchanged.
PoolState::Unreadablelanded in #183 documented as "memory the walk could not read, and which the target has". That is true of the cases the memory manager confirms committed — paged out, missing from a dump, refused by the debugger — and false of every case where no commitment query could be made at all: a kernel walk, a dump recording no memory information, a query that failed. Those are exactly whatPoolMemory::committed_run'sNonearm is for, and they land inUnreadableby design.So the asymmetry the change rests on was described backwards in the one place everyone reads it from.
Uncommittedcarries a positive answer (MEM_RESERVE/MEM_FREE);Unreadablecarries the absence of one. Reading it as confirmed memory turns we could not tell into a fact about the target, which is the single thing this walker exists not to do — anddocs/unknown-not-absent.mdis a document about exactly that mistake.Corrected at both definition sites (
PoolState::Unreadable,HeapState::Unreadable,HeapWalkReport::unreadable_gaps) and indocs/unknown-not-absent.md, which gains the paragraph stating the rule rather than leaving it implied by the table above it.🤖 Generated with Claude Code
https://claude.ai/code/session_01MUhLUt9rB6zd42Y25btB3h