GC hole in Regressions/coreclr/GitHub_119403/test119403/test119403.dll on win-x86

[jkoritzinsky]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1400682
Build error leg or test failing: Regressions/coreclr/GitHub_119403/test119403/test119403.dll

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "test119403.dll!Test119403.Problem() + 44",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1400682
Error message validated: [test119403.dll!Test119403.Problem() + 44]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 4/29/2026 6:59:04 PM UTC

Report

Build	Definition	Test	Pull Request
1400682	dotnet/runtime	Regressions.WorkItemExecution	#126108

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	1	1

[jkotas]

@mangod9

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[mangod9]

Here is some analysis:

Symptoms

test119403.dll!Test119403.Problem() + 44 crashes with:

ASSERT: "Detected use of a corrupted OBJECTREF. Possible GC hole."
at object.cpp:626, during Object::ValidateInner

The assert fires during GC.Collect() inside a catch when filter. The GC walks SubProblem's stack frame and finds a corrupted object reference at [ebp-8] — a slot that contains uninitialized data (0xBADBAD from the TrashStack() call that fills the stack with garbage before the test).

Source code of SubProblem:

static int SubProblem(string? x, string? y)
{
    int z = y.Length;     // ← FAULTS HERE (y is null) → NullReferenceException
    string s = x;        // ← NEVER REACHED — but GC reports 's' as live
    Foo(ref s);
    return z;
}

JIT-generated x86 assembly:

; x86 fastcall: ecx = x (first arg), edx = y (second arg)
offset 0: push ebp            ; prolog
offset 1: mov  ebp, esp       ;
offset 3: push esi            ; save callee-saved
offset 4: push eax            ; allocate [ebp-8] for local 's' — eax is GARBAGE here
offset 5: mov  esi, [edx+4]   ; z = y.Length ← FAULTS (edx=null) → NullReferenceException
offset 8: mov  [ebp-8], ecx   ; s = x  ← NEVER EXECUTES due to fault at offset 5
offset B: lea  ecx, [ebp-8]   ; &s
offset E: call Foo             ; Foo(ref s)

GC info for SubProblem (from dump via !gcinfo):

fully interruptible = no       ← partially interruptible method
untracked count     = 1
[EBP-08H] an untracked local   ← local 's' reported as ALWAYS live (entire method body)

The local string s at [ebp-8] is marked untracked, meaning the GC treats it as a valid object reference from prolog to epilog — including at offset 5 where s hasn't been assigned yet. When the NullReferenceException fires at offset 5, the catch when (ForceGC()) filter triggers GC.Collect(). The GC walks SubProblem's faulting frame, reads the garbage value at [ebp-8] (from push eax which used whatever was in eax at entry, NOT x), and asserts on the invalid MethodTable pointer.

The Test

test119403 was added in September 2025 by PR #119403 ("Unconditionally skip GC reporting for non-interruptible aborted methods") as a regression test for issue #119363. The test deliberately creates the conditions for this GC hole: trash the stack, fault in a method with untracked locals, trigger GC from a filter.

What Was Fixed in the New GC Info Format (and What Wasn't on x86)

PR #119403 fixed this in gcinfodecoder.cpp — the GC info decoder used by x64/arm64 (the "new" GC info format). The fix: when a partially-interruptible method's execution is aborted (exception in flight) and the current offset is NOT within an interruptible range, skip GC reporting for that frame entirely. Untracked slots may not be initialized at non-interruptible offsets, and since execution won't resume there, there's no need to report them.

x86 uses a completely different code path — EnumGcRefsX86 in eetwain.cpp (the old JIT32 GC info format). This code path was not updated with the same fix. It receives the ExecutionAborted flag (flags = 0x0002) from the stack walker but doesn't check it to skip reporting for non-interruptible aborted frames. It unconditionally reports the untracked [ebp-8] slot, reading garbage.

Why x86 Uses a Different Code Path

x86 and x64/arm64 use completely separate GC info pipelines — both for encoding (JIT side) and decoding (runtime side). The new EH funclets work did NOT unify these paths:

	x86	x64 / arm64
JIT define	JIT32_GCENCODER (jit.h:558)	(not defined)
Runtime define	USE_GC_INFO_DECODER not defined (eetwain.h:34)	USE_GC_INFO_DECODER defined
GC info format	Old JIT32 format	New GcInfo format
Decoder	EnumGcRefsX86 in gc_unwind_x86.inl	GcInfoDecoder::EnumerateLiveSlots in gcinfodecoder.cpp
Routing	eetwain.cpp:1076 #ifndef USE_GC_INFO_DECODER	eetwain.cpp:1098 #else branch
PR #119403 fix	❌ Not applied	✅ Applied

The key routing code in eetwain.cpp:

#ifndef USE_GC_INFO_DECODER          // ← x86 takes this path
bool EECodeManager::EnumGcRefs(...)
{
    return ::EnumGcRefsX86(...);      // old x86 decoder in gc_unwind_x86.inl
}
#else                                 // ← x64/arm64 take this path
bool EECodeManager::EnumGcRefs(...)
{
    GcInfoDecoder decoder(...);       // new decoder in gcinfodecoder.cpp
    return decoder.EnumerateLiveSlots(...);
}
#endif

Potential Fix

Add the equivalent of the gcinfodecoder.cpp fix to EnumGcRefsX86 in src/coreclr/vm/gc_unwind_x86.inl. For a non-interruptible aborted frame, skip all GC reporting — untracked slots may not be initialized at the faulting offset, and execution will not resume there.

The fix merges naturally into the existing prolog/epilog early-return in EnumGcRefsX86 (line 3087). Both cases are ExecutionAborted scenarios where GC slots may be uninitialized and execution will not resume — so the existing assert _ASSERTE(flags & ExecutionAborted) still holds:

diff --git a/src/coreclr/vm/gc_unwind_x86.inl b/src/coreclr/vm/gc_unwind_x86.inl
--- a/src/coreclr/vm/gc_unwind_x86.inl
+++ b/src/coreclr/vm/gc_unwind_x86.inl
@@ -3085,9 +3085,13 @@ bool EnumGcRefsX86(PREGDISPLAY     pContext,
-    /* Are we in the prolog or epilog of the method? */
+    /* Are we in the prolog or epilog of the method, or is this a
+     * non-interruptible method that will not resume execution at this
+     * offset? In either case, GC slots may not be initialized at
+     * the current offset and we can simply skip all reporting.
+     * (mirrors the fix in gcinfodecoder.cpp, PR #119403) */
 
     if (info.prologOffs != hdrInfo::NOT_IN_PROLOG ||
-        info.epilogOffs != hdrInfo::NOT_IN_EPILOG)
+        info.epilogOffs != hdrInfo::NOT_IN_EPILOG ||
+        ((flags & ExecutionAborted) && !info.interruptible))
     {
 
 #if !DUMP_PTR_REFS

[mangod9]

Feels like this failure should be more deterministic but hasn't failed till now, but possibly #126108 changed behavior/timing to repro with more frequency?

[jkotas]

this failure should be more deterministic

We have a loophole in the debug validation in GCHeap::Promote. We early out for object references that are not the GC managed range, without validating them. It means that we are effectively ignoring bogus pointers most of the time. We have to be lucky for the bogus pointer to be in the range managed by the GC for the validation to trip. #127595 has the fix.

[mangod9]

ah makes sense. I have validated that the test asserts with the Promote change, and passes with the proposed fix above.