Repository navigation
[ci-scan] Test failure: GC/API/GC/Collect_Aggressive_LargePages GC heap init fails with 0x8007000E #130302
Description
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1491722
Build error leg or test failing: coreclr Pri1 Runtime Tests Run GCStandAlone linux x64 checked @ azurelinux.3.amd64.open.rt - GC/API/GC/Collect_Aggressive_LargePages
Pipeline: runtime-coreclr gc-standalone (definition 146), branch main. The failure reproduces on the GCStandAlone linux x64 leg and persists into follow-up build 1494444.
Error Details
The GC/API/GC/Collect_Aggressive_LargePages test fails during runtime startup: the GC cannot commit a 3 GiB (0xC0000000) region for the configured large-pages heap, so coreclr_initialize aborts with E_OUTOFMEMORY (0x8007000E) and the test harness records exit code 255 against an expected 100. This is a distinct failure signature from the SIGSEGV / exit-139 manifestation of the same test tracked in #130211.
Running test: GC/API/GC/Collect_Aggressive_LargePages/Collect_Aggressive_LargePages.cmd
GC: Committing 3221225472 bytes for a region failed
GC heap initialization failed with error 0x8007000E
BEGIN: coreclr_initialize failed - Error: 0x8007000e
END: coreclr_initialize failed - Error: 0x8007000e
Expected: 100
Actual: 255
END EXECUTION - FAILED
Xunit.Sdk.TrueException: GC: Committing 3221225472 bytes for a region failed
Error Message
{
"ErrorMessage": [
"GC: Committing 3221225472 bytes for a region failed",
"GC heap initialization failed with error 0x8007000E"
],
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}First build it occurred
Earliest occurrence of this heap-init OOM signature in the scanned window is build 1470804 (2026-06-18); the immediately preceding build 1466400 (2026-06-16) does not contain it. The signature then recurs continuously through source build 1491722 (2026-07-02) and follow-up build 1494444 (2026-07-05).
Duplicate search
Searched open and closed Known Build Error issues for Collect_Aggressive_LargePages, GC heap initialization failed, and 0x8007000E: no existing KBE matches this heap-init OOM signature. Related: #130211 tracks the same test on the same leg failing with a SIGSEGV (exit 139); that issue's signature (Collect_Aggressive_LargePages.sh: line 248: plus a segfault) does not appear in this exit-255 heap-init OOM log, so Build Analysis will not auto-associate the two. Both share first-occurrence build 1470804 and are likely the same broken large-pages GC test manifesting with different exit codes.
Filed by the CI outer-loop failure scanner (detection only). Mitigation — a fix PR or owner hand-off — is handled by the companion ci-failure-fix workflow, which walks open [ci-scan] KBEs.
Note
This issue was generated with the assistance of GitHub Copilot (AI). Signatures and build references were verified against public AzDO / Helix logs.
Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
dotnet.github.io
To allow these domains, add them to the
network.allowedlist in your workflow frontmatter:
network:
allowed:
- defaults
- "dotnet.github.io"See Network Configuration for more information.
Note
🔒 Integrity filter blocked 20 items
The following items were blocked because they don't meet the GitHub integrity level.
- #86273
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #114222
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #127571
search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #130289
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7096
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5984
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5158
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5637
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5101
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #44158
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5318
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7231
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #5130
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #129960
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #55803
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #71338
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - ... and 4 more items
To allow these resources, lower min-integrity in your GitHub frontmatter:
tools:
github:
min-integrity: approved # merged | approved | unapproved | noneGenerated by CI Outer-Loop Failure Scanner · ● 18M · ◷
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 3 | 12 |
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Activity
JulieLeeMSFT commentedon Jul 7, 2026
deplicate #130266
dotnet-policy-service commentedon Jul 9, 2026
Tagging subscribers to this area: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.
janvorli commentedon Jul 14, 2026
These issues are all in gc-standalone pipeline. I can repro it locally. The GC initialization fails in case large pages are requested with GC in segments mode.
github-actions commentedon Jul 23, 2026
Workflow artifact: ci-fix
Artifact kind: handoff
Linked KBE: #130302
Root-cause analysis (read-only hand-off)
GC/API/GC/Collect_Aggressive_LargePagesfails during runtime startup on theruntime-coreclr gc-standalone(def 146) linux-x64 checked leg: the GC cannot commit a 3 GiB large-pages region, socoreclr_initializeaborts:This is a GC / large-pages product+infra defect, not a test issue. It is a distinct exit-255 heap-init-OOM signature of the same test tracked with a SIGSEGV (exit 139) in #130211 — Build Analysis will not auto-associate them, but both share first-occurrence build 1470804 (2026-06-18) and are very likely the same broken large-pages GC scenario. GC product fixes (and the question of whether the large-pages queue can even reserve 3 GiB) are out of bounds for an automated PR, and there is no correct test-side change.
Evidence
Suggested reviewers / area contacts
area-GC-coreclr:@anicka-net,@dotnet/gcNote
This root-cause hand-off was generated by an AI/Copilot agent (
ci-failure-fix). No code change was produced because the failure is a GC heap-initialization/large-pages defect that must not be worked around in test code. Please verify before acting.Warning
Firewall blocked 1 domain
The following domain was blocked by the firewall during workflow execution:
awmgmcpgSee Network Configuration for more information.
VincentBu commentedon Jul 28, 2026
Failed in: gc-standalone 20260726.1
Failed tests:
Error message:
Stack trace:
janvorli commentedon Aug 4, 2026
@JulieLeeMSFT we still seem to be running the gc-standalone leg. I have thought you have paused it.
janvorli commentedon Aug 7, 2026
The test is incompatible with GC segments mode which we test in the gc-standalone leg, because it sets the DOTNET_GCHeapHardLimit and DOTNET_GCLargePages together and that combination cannot work with segments.
I'll leave the issue open until the gc-standalone leg is really suspended.