A query that finds nothing ends the region, rather than being stepped over - #108
Conversation
… over #104, settled by the measurement it asked for. The stall diagnostic now carries the engine's own answer, and on live 26100 every sample carried the same one: `0x0+0x0`. Not a region reported behind the cursor, not a zero-length region reported ahead of it — the third possibility, which is the engine saying it found nothing valid in the span it was asked about. That is a statement about every byte through to the end of the span, so the page step asks a question that has already been answered. The eight verbatim samples were eight *consecutive* pages — one dead region stepping itself into the give-up bound, eight KD round trips to be told eight times what the first answer said. Across one walk that was ~1,100 stalled pages, and `recovered_bytes` was zero on four separate runs. So `0x0+0x0` ends the region, exactly as the sibling answer that names a base past the end already does, and just as quietly: a region running out of readable content is not a fault, and #94 was raised because saying so 3,285 times drowned out everything that meant something. The bytes are still filed as unreadable and `complete` still clears. The page step stays for the other shape. A query that reports a region and cannot size it has said nothing about what lies behind it, and that is the case #94's coverage half was written for — `test_a_stalled_query_costs_a_page_not_the_region` still pins it, and still recovers two pages.
|
Warning Review limit reached
Next review available in: 54 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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/dbgscope#108 and #109 are in main at 40f79cd: a valid-region query that finds nothing now ends the region instead of being stepped over a page at a time, and the unplaced-chunk diagnostic says which of its two causes it met. Live figures for that pin, from the tier: stalled_pages 1,121 -> 0, skipped_bytes 4,558,800 -> 0, refused_chunks 0, diagnostics 2,249 -> 1,014 in 9 categories, chunk count flat.
glslang/dbgscope#108 and #109 are in main at 40f79cd: a valid-region query that finds nothing now ends the region instead of being stepped over a page at a time, and the unplaced-chunk diagnostic says which of its two causes it met. Live figures for that pin, from the tier: stalled_pages 1,121 -> 0, skipped_bytes 4,558,800 -> 0, refused_chunks 0, diagnostics 2,249 -> 1,014 in 9 categories, chunk count flat.
Closes #104. Verified on the same live 26100 target.
What the measurement said
#104 asked whether
recovered_bytes: 0meant nothing was behind those stalls ornothing was being counted. It was the former — but the interesting part is why,
which the previous PR's diagnostic was added to find out. Every verbatim sample
carried the same answer:
Neither of the two shapes I expected.
0x0+0x0is not a region at zero — it is theengine reporting that it found nothing valid in the span it was asked about, which is
a statement about every byte through to the end of that span. And the eight samples
are eight consecutive pages: one dead region stepping itself into the give-up bound,
eight KD round trips to be told eight times what the first answer already said.
So the page step was asking a question that had been answered. That is exactly the
sibling case #94's quiet half already handles — an engine naming a base past the end —
in the engine's other encoding, and it gets the same response, just as quietly. A
region running out of readable content is not a fault, and #94 was raised because
saying so 3,285 times drowned out the diagnostics that meant something. The bytes are
still filed as unreadable and
completestill clears.The page step stays for the other shape. A query that reports a region and cannot
size it has said nothing about what lies behind it, which is the case the coverage half
of #94 was written for.
test_a_stalled_query_costs_a_page_not_the_regionstill pinsit, and still recovers two pages.
Measured, same target
stalled_pages/skipped_bytes~1,100 round trips removed over a KD link, and no coverage lost — the chunk count is
flat inside the noise of two walks of a live target.
Taken with #107, one walk of this target has gone from 3,569 diagnostics in 14
categories to 1,014 in 9, with
refused_chunks106,516 → 0 andstalled_pages1,619 → 0. What remains is genuine: commit holes, a handful of unreadable tree nodes,
and the 19 VS extents whose chunk chain could not be placed.
Verification
cargo test(125 pass),cargo clippy --all-targetsclean, live tier green. The newtest was checked against the old behaviour: 5 queries where it now takes 2.