Test failure: GC stress assertion !CREATE_CHECK_STRING(pMT && pMT->Validate()) in object.cpp on x64 (Loader explicit-layout/generics tests)

[JulieLeeMSFT]

Summary:
Under gcstress0x3 on x64, the Loader explicit-layout negative tests (objrefandnonobjrefoverlap/case15 MyUnion2, case11 WrapFoo) and the SelfRecursiveGenerics test abort. Each test deliberately loads an invalid type, so a System.TypeLoadException is expected; but while that exception propagates, a GC stackwalk validates an object whose MethodTable is inconsistent and trips !CREATE_CHECK_STRING(pMT && pMT->Validate()) at vm/object.cpp:548 (exit code -1073740286 instead of the expected 100).

Build Information:

• runtime-coreclr gcstress0x3-gcstress0xc 20260613.1

Error Message:

15:13:06.583 Running test: Loader/classloader/explicitlayout/objrefandnonobjrefoverlap/case15/case15.dll
System.TypeLoadException: Could not load type 'MyUnion2' from assembly 'case15, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.
   at Test.Go()
   at Test.TestEntryPoint()

Assert failure(PID 32404 [0x00007e94], Thread: 32396 [0x7e8c]): !CREATE_CHECK_STRING(pMT && pMT->Validate())

CORECLR! Object::ValidateInner + 0x135 (0x00007ffa`0d6e4eb5)
CORECLR! Object::Validate + 0xB0 (0x00007ffa`0d6e4d40)
CORECLR! TGcInfoDecoder<AMD64GcInfoEncoding>::ReportStackSlotToGC + 0x165 (0x00007ffa`0db95c35)
CORECLR! TGcInfoDecoder<AMD64GcInfoEncoding>::EnumerateLiveSlots + 0x185D (0x00007ffa`0db911ad)
CORECLR! EECodeManager::EnumGcRefs + 0x2E7 (0x00007ffa`0d58f737)
CORECLR! GcStackCrawlCallBack + 0x34B (0x00007ffa`0d8bf15b)
CORECLR! Thread::StackWalkFramesEx + 0x1FE (0x00007ffa`0d74b5ae)
CORECLR! Thread::StackWalkFrames + 0x1D1 (0x00007ffa`0d74b381)
CORECLR! ScanStackRoots + 0x2D0 (0x00007ffa`0d8bbc50)
CORECLR! GCToEEInterface::GcScanRoots + 0x1C2 (0x00007ffa`0d8b9132)
    File: D:\a\_work\1\s\src\coreclr\vm\object.cpp:548
    Image: C:\h\w\B78609C9\p\corerun.exe

Exit Code: -1073740286
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED

Affected test legs:

runtime-coreclr gcstress0x3-gcstress0xc
- coreclr windows x64 Checked gcstress0xc @ Windows.10.Amd64.Open
    - Loader.1.3
- coreclr windows x64 Checked gcstress0xc @ Windows.10.Amd64.Open
    - Loader.2.3
- coreclr windows x64 Checked gcstress0xc @ Windows.10.Amd64.Open
    - LoaderClassloaderGenerics.0.1

Console log: Console Log

Source: runtime-coreclr gcstress0x3-gcstress0xc / coreclr windows x64 Checked gcstress0xc @ Windows.10.Amd64.Open / Loader.1.3

Analysis:
The tests load deliberately-invalid types (explicit-layout structs overlapping an object field with a non-object field, or a self-recursive generic the type loader cannot handle), so a System.TypeLoadException is expected. Under GC stress, a stackwalk (Thread::StackWalkFrames -> EECodeManager::EnumGcRefs -> Object::Validate) runs while the type is in a half-loaded/invalid state and the Object::Validate check !CREATE_CHECK_STRING(pMT && pMT->Validate()) asserts at src/coreclr/vm/object.cpp:548, aborting the process (exit -1073740286). This is the x64 manifestation; the same assert was previously seen and tracked on x86 in #128995 (gcstress-extra, HardwareIntrinsics/Directed work items).

Related issues:

• Bad GC info during ReadOnlySpan<T> byref copy #128801 — Bad GC info during ReadOnlySpan byref copy (GC stack scanning reports a bad interior pointer; likely the same class of bad-GC-info root cause).
• [ci-scan] GC stress assertion: CREATE_CHECK_STRING(pMT && pMT->Validate()) in object.cpp #128995 — same !CREATE_CHECK_STRING(pMT && pMT->Validate()) assert at object.cpp:548 on x86.

Milestone: 11.0.0

Note

This issue was generated with assistance from GitHub Copilot (AI).

[dotnet-policy-service]

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

[EgorBo]

Same root cause as #129546 — this is a VM exception-dispatch / GC-stackwalk bug, not a JIT (codegen) bug. Full analysis, minimal repro, and the candidate fix area are here: #129546 (comment #129546 (comment)).

Summary: a GC ref held in a callee-saved register live across a call that throws TypeLoadException from the callee's prestub is mis-recovered during a GC stackwalk while the exception dispatches — the PrestubMethodFrame (which saved that register in its TransitionBlock) is popped and the caller frame is scanned as active with the live/redirected context. The JIT's codegen, GC info and unwind for the affected method are all correct. Reproduces under DOTNET_GCStress=0x3 and 0xC, with both legacy and new EH, and is long-standing (not a recent regression).

Re-routing to area-VM-coreclr (the area-ExceptionHandling-coreclr label is marked closed-issues-only).

[dotnet-policy-service]

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