fix(rallocator): keep stack-grouped allocations on a single call site - #748
Merged
Merged
Conversation
The release profile fully unrolls the constant-trip-count loop in `snapshot_encodes_allocations_by_stack`, so each sample allocated from its own call site and recorded its own return address. Call stacks are captured as raw return addresses, so the four samples landed in four stack buckets and the grouping assertion saw 1 allocation instead of 4. Route every sample through a single `#[inline(never)]` helper and make the loop bound opaque, so all samples allocate from one instruction and share one recorded call stack. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The release test is hardened and no unresolved issues remain.
Pull request overview
Fixes release-profile telemetry test flakiness by keeping stack-grouped allocations at one call site.
Changes:
- Adds a non-inlined allocation helper.
- Makes the loop bound opaque.
- Derives the expected count from the sample constant.
File summaries
| File | Description |
|---|---|
crates/rallocator/tests/telemetry.rs |
Stabilizes stack-grouped allocation testing in optimized builds. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #748 +/- ##
======================================
Coverage 99.9% 100.0%
======================================
Files 634 634
Lines 84746 84746
======================================
+ Hits 84744 84746 +2
+ Misses 2 0 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
martintmk
approved these changes
Sep 11, 2026
Zac Walker (ZacWalk)
enabled auto-merge (squash)
September 11, 2026 11:34
martin-kolinek
approved these changes
Sep 11, 2026
Zac Walker (ZacWalk)
deleted the
fix/rallocator-stack-test-unrolling
branch
September 11, 2026 11:51
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
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.
Root cause
OxidizerGitHub.PublishEachCommitis red onmain. TheCargo teststep fails in the release profile on both Linux and Windows (dev passes), with one failing test out of ~7,700:The last green and the first red run used the same toolchain (
1.97.1-ms-20260901.3), so this is a code regression, not a tooling migration:snapshot_encodes_allocations_by_stackallocates in a loop with a compile-time trip count and asserts that all four samples share one call stack. Call stacks are recorded as raw return addresses incapture_platform_stack, and the release profile fully unrolls that loop, so each sample allocates from its own call site. Instrumenting the test confirms all four allocations are recorded, but their stacks differ in exactly one frame - the return address inside the test function, stepping by a fixed instruction offset per iteration:The grouping filter therefore matches 1 event instead of 4. The allocations are not elided, they are split across four stack buckets. #733 reworked the allocation path and changed inlining enough to tip this loop into being unrolled; the test has never been protected against release codegen. This is the same class of fragility as #666 (
fix(rallocator): preserve allocation effects in release tests), where LLVM elided unprotected test allocations.Fix
Route every sample through a single
#[inline(never)]helper and make the loop bound opaque, so all samples allocate from one instruction and record one shared call stack.black_boxalone would not fix this, since the allocations do occur - the call site itself has to stay singular.Validation
Against the exact CI toolchain (
ms-prod-1.97@llvm,1.97.1-ms-20260901.3):cargo test --release --all-features -p rallocator --test telemetry- fails onmainbefore the change, 19/19 pass after itcargo test --all-features -p rallocator --test telemetry(dev profile) - 19/19 passcargo clippy --release --all-features -p rallocator --all-targets -- -D warnings- cleancargo +nightly-2026-05-30 fmt -p rallocator -- --check- cleanjust anvil-spellcheck- cleanAlso reproduced and verified on 1.96.1; the failure does not reproduce on 1.95.0.
Bug: https://o365exchange.visualstudio.com/O365%20Core/_workitems/edit/7866558
Failing build: https://dev.azure.com/O365Exchange/O365%20Core/_build/results?buildId=40955158&view=results
First failing build: https://dev.azure.com/O365Exchange/O365%20Core/_build/results?buildId=40907883&view=results