Repository navigation
[ci-scan] Test failure: GC object corruption assert (Object::ValidateInner) in runtime-coreclr jit-cfg #129835
Description
Activity
Workflow artifact: ci-fix
Artifact kind: handoff
Linked KBE: #129835Root-cause analysis (read-only hand-off)
Under Control-Flow-Guard mode (
runtime-coreclr jit-cfg, AzDO definition 155) the Loader and Regressions work items abort during GC stack enumeration:Assert failure: !"Detected use of a corrupted OBJECTREF. Possible GC hole." Object::ValidateInner TGcInfoDecoder<AMD64GcInfoEncoding>::ReportRegisterToGC TGcInfoDecoder<AMD64GcInfoEncoding>::EnumerateLiveSlots EECodeManager::EnumGcRefsA register/stack slot that
GcInforeports as containing a live object reference actually holds non-object data, so the GC dereferences a corruptedOBJECTREF. That is a JIT/GcInfo codegen defect (the GC-liveness reporting emitted by the JIT under CFG is inaccurate), not a test-side problem. Affected tests areclassloader/explicitlayout/objrefandnonobjrefoverlap/case13andRegressions/coreclr/25057/byref/byref.dll.Per this workflow's rules JIT/GC codegen fixes are out of bounds for an automated PR (no safe product diff, and a test-side workaround would only mask the GC hole), so this is a hand-off rather than a fix.
Evidence
- Failing build: 1494697 (leg
Loader.2.3/Regressions.0.1). - First failing build in window: 1452746 (2026-06-07); the prior build 1442662 (2026-06-01) passed.
- Affected pipelines:
runtime-coreclr jit-cfg(def 155) — windows x64 checked, windows arm64 checked. - Possibly related: Test failure: GC stress assertion !CREATE_CHECK_STRING(pMT && pMT->Validate()) in object.cpp on x64 (Loader explicit-layout/generics tests) #129545, Test failure: GC stress assertion (GetComponentSize() <= 2) || IsArray() in methodtable.cpp on x64 (Loader explicit-layout objrefandnonobjrefoverlap/case1) #129546 (same
Object::ValidateInnerGC-hole asserts in Loader tests undergcstress) — a shared GcInfo root cause is plausible.
Suggested reviewers / area contacts
area-CodeGen-coreclr:@JulieLeeMSFT,@dotnet/jit-contrib
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 JIT/GC codegen defect that must not be worked around in test code. Please verify before acting.Note
🔒 Integrity filter blocked 6 items
The following items were blocked because they don't meet the GitHub integrity level.
- #128501
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #104998
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #104750
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #97491
search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - [ci-scan] Test failure: AsyncProfilerTests.StateMachineAsync_CallstackStressWithVaryingDepths under libraries-jitstress #129938
issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - [ci-scan] Test failure: System.Threading.Tests.MutexTests.CrossProcess_NamedMutex_ConcurrentCreateOrOpen #130125
issue_read: 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:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by CI Outer-Loop Failure Fixer · ● 9.2M · ◷
- Failing build: 1494697 (leg
possible duplicate #129959.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.This is the same VM exception-dispatch / GC-stackwalk bug diagnosed in #129546 (not a JIT codegen defect): a GC ref held in a callee-saved register live across a call is mis-recovered during a GC stackwalk while a
TypeLoadExceptionthrown from the prestub dispatches. CFG mode just widens the window. Root cause + minimal repro: #129546 (comment)Duplicates / same root cause:
- Test failure: GC stress assertion !CREATE_CHECK_STRING(pMT && pMT->Validate()) in object.cpp on x64 (Loader explicit-layout/generics tests) #129545
- Test failure: GC stress assertion (GetComponentSize() <= 2) || IsArray() in methodtable.cpp on x64 (Loader explicit-layout objrefandnonobjrefoverlap/case1) #129546
- Assert failure "!CREATE_CHECK_STRING(pMT && pMT->Validate())" in System.Text.RegularExpressions.Tests #129959
Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.- locked and limited conversation to collaborators
on Aug 15, 2026
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1474087
Build error leg or test failing: coreclr Pri1 Runtime Tests Run windows x64 checked-Loader.2.3
Error Details
Under CFG (Control Flow Guard) mode in
runtime-coreclr jit-cfg(definition 155), the Loader and Regressions work items crash with a GC object validation assertion. TheObject::ValidateInnerfunction detects a corrupted OBJECTREF during GC enumeration of live slots, indicating a GC hole where a register or stack slot that GcInfo reports as containing an object reference actually holds corrupted data.Affected tests include
classloader/explicitlayout/objrefandnonobjrefoverlap/case13andRegressions/coreclr/25057/byref/byref.dll.Affected pipelines:
First build it occurred: Build 1452746 (June 7, 2026). Prior build 1442662 (June 1) succeeded. 6 consecutive failures in window.
Related issues: #129545, #129546 (same GC validation asserts in Loader tests under gcstress)
Error Message
{ "ErrorMessage": ["Detected use of a corrupted OBJECTREF. Possible GC hole.", "Object::ValidateInner"], "ErrorPattern": "", "BuildRetry": false, "ExcludeConsoleLog": false }Note
🔒 Integrity filter blocked 13 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_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