-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Execution
-
ALL
-
QE 2026-09-15
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
BF-46094 exposed a stack-overflow risk in recursive SBE aggregation lowering on ARM64 after the SERVER-110427 PGO profile refresh.
The failing test constructs a legal 1,000-stage aggregation pipeline. Each $group is lowered through SlotBasedStageBuilder::buildGroup(), which recursively calls build() for the child. The PGO/BOLT layout change appears to move the optimized binary across the stack-use threshold; the failure surfaces in computeChildReqsForGroup()/PlanStageReqs::setResultObj() as an invalid access / SIGSEGV.
Evidence:
- Failed PGO waterfall (order 86004): https://spruce.mongodb.com/version/sys_perf_3326cb84e7c5e71d873b575a57a4ec933cfda49e/tasks
- Failed mainline order: 86004, caused by SERVER-110427 Update profiling data (#62029), revision 3326cb84e7c5e71d873b575a57a4ec933cfda49e
- BF: https://jira.mongodb.org/browse/BF-46094
- Successful validation with SBE cap 100: https://spruce.mongodb.com/version/6a9745aff64c910007517082/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC
- Successful validation patch: 6a9745aff64c910007517082, message "BF-46094: rerun all failing ARM64 aggregation tasks with SBE cap 100"
Request:
Reduce the effective SBE aggregation pipeline lowering threshold from the current 1,000-stage limit to 100 stages, or implement an equivalent SBE-specific lowering cap with a safe fallback to classic execution. Preserve the documented 1,000-stage pipeline behavior where feasible, but do not allow deep recursive SBE lowering to exhaust the thread stack.
Acceptance criteria:
- query_limits_test.js passes on the affected ARM64 optimized and all-feature-flags variants with the current PGO/BOLT build.
- A deep pipeline cannot trigger a stack-guard-page fault during SBE lowering.
- Add or update regression coverage for the safe SBE lowering depth and document any compatibility impact of lowering the effective SBE cap.
Additional context and tradeoff
Tradeoff: lowering the SBE lowering-depth cap intentionally limits SBE pushdown for unusually deep pipelines. Stages beyond the cap remain in Classic, so this can reduce SBE runtime and PGO coverage for those deep shapes in exchange for stack safety. It does not prevent the compiler from optimizing SBE functions globally or affect pipelines within the safe bound.
If this tradeoff is unacceptable, the long-term fix is an iterative SBE stage-builder refactor rather than a lower cap.
- is related to
-
SERVER-134768 Reduce buildSort stack frame size to reduce likelihood of stack overflow with some PGO profiles
-
- Closed
-
-
SERVER-110427 Update Profile Data Files
-
- Backlog
-
-
SERVER-134346 Update PGO profiles
-
- Closed
-
-
SERVER-134427 Update PGO profiles
-
- Closed
-
- links to