Repository navigation
[ci-scan] Test failure: GC/API/GC/Collect_Aggressive_LargePages GC heap init fails with 0x8007000E #130302
Description
Activity
deplicate #130266
Tagging subscribers to this area: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.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.
Workflow artifact: ci-fix
Artifact kind: handoff
Linked KBE: #130302Root-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:GC: Committing 3221225472 bytes for a region failed GC heap initialization failed with error 0x8007000E (E_OUTOFMEMORY) BEGIN: coreclr_initialize failed - Error: 0x8007000e Expected: 100 Actual: 255This 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
- Source build 1491722, persists in follow-up 1494444.
- Earliest in window: 1470804 (2026-06-18); preceding 1466400 (2026-06-16) is clean.
- Likely same underlying defect as [ci-scan] Test failure: GC/API/GC/Collect_Aggressive_LargePages segfaults with SIGSEGV #130211 (consider consolidating).
Suggested reviewers / area contacts
area-GC-coreclr:@anicka-net,@dotnet/gc
Note
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:
awmgmcpg
To allow these domains, add them to the
network.allowedlist in your workflow frontmatter:network: allowed: - defaults - "awmgmcpg"
See Network Configuration for more information.
Generated by CI Outer-Loop Failure Fixer · 520.3 AIC · ⌖ 18.1 AIC · ⊞ 17.1K · ◷
Failed in: gc-standalone 20260726.1
Failed tests:
coreclr linux x64 Checked gcstandalone @ AzureLinux.3.Amd64.Open - GC/API/GC/Collect_Aggressive_LargePages/Collect_Aggressive_LargePages.cmd coreclr linux arm64 Checked gcstandalone @ AzureLinux.3.Arm64.Open - GC/API/GC/Collect_Aggressive_LargePages/Collect_Aggressive_LargePages.cmdError message:
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 Return code: 1 Raw output file: /datadisks/disk1/work/B2B109D7/w/AABF095C/uploads/API/GC/Collect_Aggressive_LargePages/output.txt Raw output: BEGIN EXECUTION /datadisks/disk1/work/B2B109D7/p/corerun -p System.Reflection.Metadata.MetadataUpdater.IsSupported=false -p System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true Collect_Aggressive_LargePages.dll '' Exe path: /datadisks/disk1/work/B2B109D7/p/corerun Properties: TRUSTED_PLATFORM_ASSEMBLIES = /datadisks/disk1/work/B2B109D7/p/System.Reflection.Metadata.dll:/datadisks/disk1/work/B2B109D7/p/System.Threading.Channels.dll:/datadisks/disk1/work/B2B109D7/p/System.IO.Packaging.dll:/datadisks/disk1/work/B2B109D7/p/System.Diagnostics.Debug.dll:/datadisks/disk1/work/B2B109D7/p/xunit.runner.utility.netcoreapp10.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Bcl.Memory.dll:/datadisks/disk1/work/B2B109D7/p/System.IO.FileSystem.Primitives.dll:/datadisks/disk1/work/B2B109D7/p/System.Diagnostics.StackTrace.dll:/datadisks/disk1/work/B2B109D7/p/System.Net.ServerSentEvents.dll:/datadisks/disk1/work/B2B109D7/p/System.Security.Cryptography.Cng.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.Options.ConfigurationExtensions.dll:/datadisks/disk1/work/B2B109D7/p/System.ComponentModel.DataAnnotations.dll:/datadisks/disk1/work/B2B109D7/p/System.Net.Ping.dll:/datadisks/disk1/work/B2B109D7/p/System.Configuration.dll:/datadisks/disk1/work/B2B109D7/p/System.Text.Json.dll:/datadisks/disk1/work/B2B109D7/p/System.Text.Encoding.dll:/datadisks/disk1/work/B2B109D7/p/System.Numerics.Vectors.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.CodeAnalysis.dll:/datadisks/disk1/work/B2B109D7/p/System.Globalization.dll:/datadisks/disk1/work/B2B109D7/p/System.Diagnostics.Contracts.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Bcl.Numerics.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.Options.dll:/datadisks/disk1/work/B2B109D7/p/System.Private.Xml.Linq.dll:/datadisks/disk1/work/B2B109D7/p/System.Reflection.Extensions.dll:/datadisks/disk1/work/B2B109D7/p/System.Transactions.dll:/datadisks/disk1/work/B2B109D7/p/System.Collections.Immutable.dll:/datadisks/disk1/work/B2B109D7/p/System.Threading.Overlapped.dll:/datadisks/disk1/work/B2B109D7/p/System.IO.Pipes.AccessControl.dll:/datadisks/disk1/work/B2B109D7/p/System.Runtime.Serialization.Primitives.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.Caching.Memory.dll:/datadisks/disk1/work/B2B109D7/p/System.Reflection.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Bcl.TimeProvider.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.FileProviders.Physical.dll:/datadisks/disk1/work/B2B109D7/p/System.Xml.Linq.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.Diagnostics.Abstractions.dll:/datadisks/disk1/work/B2B109D7/p/System.Runtime.Serialization.Xml.dll:/datadisks/disk1/work/B2B109D7/p/FSharp.Core.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Extensions.Hosting.dll:/datadisks/disk1/work/B2B109D7/p/System.Xml.Serialization.dll:/datadisks/disk1/work/B2B109D7/p/System.Management.dll:/datadisks/disk1/work/B2B109D7/p/xunit.runner.reporters.netcoreapp10.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Diagnostics.FastSerialization.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.CodeAnalysis.CSharp.dll:/datadisks/disk1/work/B2B109D7/p/System.Net.WebProxy.dll:/datadisks/disk1/work/B2B109D7/p/System.Drawing.Primitives.dll:/datadisks/disk1/work/B2B109D7/p/System.Runtime.Numerics.dll:/datadisks/disk1/work/B2B109D7/p/System.Net.NameResolution.dll:/datadisks/disk1/work/B2B109D7/p/System.IO.dll:/datadisks/disk1/work/B2B109D7/p/System.Linq.Parallel.dll:/datadisks/disk1/work/B2B109D7/p/Microsoft.Bcl.Cryptography.dll:/datadisks/disk1/work/B2B109D7/p/System.DirectoryServices.dll:/datadisks/disk1/work/B2B109D7/p/MicrosStack trace:
at Xunit.Assert.True(Nullable`1 condition, String userMessage) in /_/src/arcade/src/Microsoft.DotNet.XUnitAssert/src/BooleanAsserts.cs:line 135 at Program.<<Main>$>g__TestExecutor24|0_25(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)@JulieLeeMSFT we still seem to be running the gc-standalone leg. I have thought you have paused it.
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.- marked [ci-scan] Test failure: GC/API/GC/Collect_Aggressive_LargePages heap commit fails (0x8007000E) #134293 as a duplicate of this issue
on Sep 22, 2026
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), branchmain. The failure reproduces on the GCStandAlone linux x64 leg and persists into follow-up build 1494444.Error Details
The
GC/API/GC/Collect_Aggressive_LargePagestest fails during runtime startup: the GC cannot commit a 3 GiB (0xC0000000) region for the configured large-pages heap, socoreclr_initializeaborts withE_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.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 Errorissues forCollect_Aggressive_LargePages,GC heap initialization failed, and0x8007000E: 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-fixworkflow, 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.ioSee 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.
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".To allow these resources, lower
min-integrityin your GitHub frontmatter:Report
Summary