Wasm / R2R: struct-returning instance method via field reference asserts in dispatch helper

[AndyAyersMS]

Description

On wasm with R2R, calling a (virtual or non-virtual) instance method that returns a
struct via an intermediate instance method appears to corrupt this (or the field
load) and ends up dispatching on a null/garbage MethodTable.

The original failing test is JIT/opt/OSR/synchronized, which manifests as an
object.cpp:548 pMT->Validate() assert during VirtualDispatchHelpers::ResolveVirtualFunctionPointer:

ASSERT FAILED
        Expression: !CREATE_CHECK_STRING(pMT && pMT->Validate())
        Location:   src/coreclr/vm/object.cpp:548
   0) System.Runtime.CompilerServices.VirtualDispatchHelpers::ResolveVirtualFunctionPointer
   1) System.Runtime.CompilerServices.VirtualDispatchHelpers::VirtualFunctionPointerSlow
   2) System.Runtime.CompilerServices.VirtualDispatchHelpers::VirtualFunctionPointer
   3) System.Environment::CallEntryPoint

A minimized variant produces a clean managed exception that points at the same root
cause (helper sees a null object → MT validation fails):

System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Runtime.CompilerServices.RuntimeHelpers.GetMethodTable(Object obj)
   at X.G()
   at X.TestEntryPoint()
   at __GeneratedMainWrapper.Main()

Minimal Repro

using System.Runtime.CompilerServices;
using Xunit;

struct S { public long y; public int x; }

class Z { public virtual S F() => new S { x = 100, y = -1 }; }

public class X
{
    Z z;

    [MethodImpl(MethodImplOptions.NoInlining)]
    internal S G() => z.F();

    [Fact]
    public static int TestEntryPoint()
    {
        var x = new X();
        x.z = new Z();
        return x.G().x;   // expected 100
    }
}

Bisection of contributing factors

Variants of JIT/opt/OSR/synchronized.cs were run as wasm R2R; the failing
ingredient is the struct-returning instance method called through an intermediate
non-inlined method on a class field, independent of Synchronized and independent
of looping:

Variant	Method G body	Z.F return	Repros?
A (baseline)	Synchronized + for { z.F() } loop	struct S	yes — pMT->Validate assert
B	Drop Synchronized, keep loop	struct S	yes — same assert
C	Sealed Z, direct (non-virtual) call	struct S	no
D	G() => z.F() (no loop)	int	no
E/H	for { z.F() } loop	struct S	yes — NRE on GetMethodTable(null)
F/G	for { sum += z.F() } loop	int	no
I	G() => z.F(); (no loop)	struct S	yes — same NRE
J	G() => z.F(); (sealed Z, non-virtual)	struct S	yes — same NRE
K	Drop G, inline at call site	struct S	inconclusive — different cctor assert (gchelpers.cpp:573 HasEmptySyncBlockInfo) masks
L	Variant I, but z rooted in a static	struct S	yes — same NRE (so not a GC reclaim of z)

Common ingredient in all repros: an instance method G() on a class with a field of
reference type Z, where G returns a struct produced by calling z.F(). Variant L
confirms the issue is not GC reclaiming z — it persists even when z is rooted by a
static field.

Workaround

DOTNET_ReadyToRunExcludeList=synchronized (or the minimal-repro assembly name) makes
the test pass. Disabling R2R entirely (DOTNET_ReadyToRun=0) also works.

Notes / Suspected scope

• Probably an R2R codegen issue around struct returns + a hidden retbuf argument
  interacting with the this arg, exposed when z.F() is invoked through an
  intermediate method. The MethodTable that reaches the dispatch helper is null or
  garbage.
• The assert location matches [wasm][coreclr] !CREATE_CHECK_STRING(pMT && pMT->Validate()) assert failures #121107 but the failing call path is different (that
  issue was about an unhandled PlatformNotSupportedException rethrow path).
• Possibly an interaction with [Wasm R2R] Bypass dynamic LDVIRTFTN helper #129075 which routed wasm R2R LDVIRTFTN calls through
  CORINFO_HELP_VIRTUAL_FUNC_PTR, but variant J (non-virtual Z) repros without that
  helper being involved — so the issue is broader than the virtual-dispatch helper.

cc @AndyAyersMS @davidwrighton @janvorli

Note

This issue was drafted with assistance from GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[AndyAyersMS]

Note

AI-generated by GitHub Copilot.

Triage of a wider wasm R2R .cmd sweep surfaced 4 additional repros for what appears to be the same root cause (wasm struct return via GDV / hidden retbuf / type-context arg in wrong slot — the pattern explicitly described in the test comment on structreturningstruct.cs linking to #52975):

Test	Pattern	Stderr signature
JIT/opt/Devirtualization/structreturningstruct	Interface call → struct return via hidden retbuf + type context arg	TestEntryPoint prints Result=100 but returns 12345 (also reproduces with DOTNET_ReadyToRun=0 — wasm JIT, not just R2R)
JIT/Regression/JitBlue/Runtime_53549	GDV on interface call returning Decimal	pMT->Validate() assert at methodtable.cpp:8626 in VirtualDispatchHelpers::ResolveVirtualFunctionPointer
JIT/Regression/JitBlue/Runtime_53549_1	Virtual override returning Decimal via derived class	Process terminated. hiProd + 1 < Buf24.Length in Decimal.DecCalc.DecAddSub (with duplicated stack frames)
JIT/Regression/JitBlue/Runtime_65694_2	Returns StructWithObj by value across GC.Collect	pMT->Validate() assert during System.GC._Collect P/Invoke

All four bypass with DOTNET_ReadyToRunExcludeList=<testname> (and structreturningstruct also bypasses with DOTNET_ReadyToRun=0). None of the tests use try/catch/finally, so this is not EH-related.

cc @AndyAyersMS

[AndyAyersMS]

Note

AI-generated by GitHub Copilot.

One more wasm R2R repro from the same sweep that appears to belong to this family (struct-by-value / GC pointer integrity across helper transitions):

Test	Pattern	Symptom
JIT/opt/OSR/Runtime_69032	ConditionalWeakTable.Add in a loop with GC.Collect() every 1000 iterations	TestEntryPoint correctly returns 100 (no exception thrown, wrapper's Assert.Equal does not fire), yet the R2R'd __GeneratedMainWrapper.Main exits 0 instead of 100. Bypasses with DOTNET_ReadyToRunExcludeList=Runtime_69032. No try/catch/finally in the test.

Same shape as Runtime_65694_2 (GC.Collect P/Invoke transition with a struct-by-value flowing across).

[AndyAyersMS]

Possibly some disagreement somewhere about the order of hidden parameters.

[AndyAyersMS]

Root cause: WasmInterpreterToR2RThunkNode arg-order swap

When an interpreter-only method (e.g. a runtime-synthesized Synchronized
wrapper, or any IL-stub) calls a R2R-compiled instance method that returns a
struct, the resulting call_indirect swaps this and the hidden retbuf
pointer. The R2R callee then reads the retbuf bytes as this, dispatches
GetMethodTable on a stack address, and asserts pMT->Validate().

Three sources, one disagreement

Source	Wasm-local order	File
JIT (lvaInitArgs / morph)	0=sp, 1=this, 2=retbuf, …, last=pep	importer.cpp:888, morph.cpp:1797
WasmR2RToInterpreterThunkNode (R2R→Interp local layout)	0=sp, 1=this, 2=retbuf, …	WasmR2RToInterpreterThunkNode.cs:162-178, line 288 retBufLocalIndex = 1 + (hasThis ? 1 : 0)
WasmInterpreterToR2RThunkNode (Interp→R2R push order)	0=sp, 1=retbuf, 2=this, … ❌	WasmInterpreterToR2RThunkNode.cs:142-172 (swapped)

The thunk's own comment at the time read
Target R2R wasm params: (, [retbuf], [this], …), which is the opposite
of what the JIT and the sister thunk node use.

Why the original synchronized test triggers it

X.G() has both [MethodImpl(Synchronized)] and a struct return. The runtime
synthesizes a Synchronized wrapper (interp-only) that calls the underlying
R2R-compiled G. That call is an Interp→R2R call with both hasThis=true
and hasRetBuffArg=true — exactly the conditions where the swap occurs.

Fix

Swap the two if blocks in EmitCode so this is pushed before retbuf
(matching the JIT/R2RToInterp convention). Committed as
5ac582f6fc7 Wasm R2R: push this before retbuf in InterpToR2R thunk args.

Verification

• Before fix: synchronized hits the pMT->Validate() assert reliably.
• After fix: assert is gone. The test prints SUCCESS (result == 100 reached
  inside TestEntryPoint), confirming the struct value now flows back from the
  R2R-compiled G through the wrapper to the caller unchanged.
• Related struct-return tests in the same family — surfaced by an EH-codegen
  bulk sweep — also improve with this single fix:
  • JIT/opt/Devirtualization/structreturningstruct now exits 100
    (previously returned 12345 with DOTNET_ReadyToRun=1).
  • JIT/Regression/JitBlue/Runtime_53549 no longer asserts in
    ResolveVirtualFunctionPointer (was the same pMT->Validate symptom).

Note

This investigation and fix were produced with assistance from GitHub Copilot.