Skip to content

[wasm] R2R: open-instance delegate over a virtual/interface method faults in the interpreter's INTOP_CALLDELEGATE #130840

Closed
#134765
Closed
[wasm] R2R: open-instance delegate over a virtual/interface method faults in the interpreter's INTOP_CALLDELEGATE#130840
#134765
Assignees
lewing
Labels
arch-wasmWebAssembly architecturearea-CodeGen-Interpreter-coreclros-iosApple iOS
Milestone
12.0.0

Description

@lewing
lewing
opened on Jul 16, 2026

Description

Under ReadyToRun on wasm, invoking an open-instance delegate whose target is a virtual or interface method faults in the interpreter: RuntimeError: memory access out of bounds (release) / NullReferenceException (checked). It passes interpreted and passes with only the corelib R2R'd; it fails when the calling method is itself R2R-compiled (so the R2R method calls the still-interpreted delegate Invoke via the R2R→interpreter thunk ExecuteInterpretedMethodWithArgs_PortableEntryPoint).

Root cause (source-pinned): The fault is in the interpreter's INTOP_CALLDELEGATE open-virtual branch (src/coreclr/vm/interpexec.cpp:3396-3405). Only open-instance delegates over a virtual/interface method reach this branch; it reads the receiver:

OBJECTREF *pThisArg = LOCAL_VAR_ADDR(callArgsOffset + INTERP_STACK_SLOT_SIZE, OBJECTREF); // 3399
NULL_CHECK(*pThisArg);                                                                     // 3400
... targetMethod->GetMethodDescOfVirtualizedCode(pThisArg, targetMethod->GetMethodTable()); // 3403

The receiver at callArgsOffset + INTERP_STACK_SLOT_SIZE is mis-located on the R2R→interpreter entry path: it holds a garbage value (observed 0x614F646C in release), so GetMethodDescOfVirtualizedCode dereferences a bad MethodTable → OOB (release), or the mislocated slot is null → NRE (checked). A valid allocated receiver always has a loaded MethodTable+EEClass, so the garbage value confirms mis-location (not a type-loading/activation gap).

The suspect is the delegate arg-shuffle sizing that "removes the delegate object from the argument list": ShiftDelegateCallArgs(stack, callArgsOffset, sizeOfArgsUpto16ByteAlignment /*ip[4]*/, targetArgsSize /*ip[5]*/) (3422/3428/3455), computed by the interpreter compiler's INTOP_CALLDELEGATE lowering — vs the actual argument layout when the delegate Invoke is entered via the PortableEntryPoint thunk's memcpy(sp, args, argsSize).

Proof (variant matrix → source branches, 1:1):

Variant Delegate / dispatch Interp branch Result
direct interface call, no delegate — no INTOP_CALLDELEGATE pass
closed delegate closed 3461 GetTarget pass
open delegate, non-virtual target open, non-virtual 3408 NonVirtualEntry2MethodDesc pass
open delegate, virtual/interface target open, virtual 3396-3405 receiver deref fault

Multi-register struct return, boxing, and the shuffle thunk itself were ruled out by the variant matrix.

Reproduction Steps

Crossgen a test to R2R that invokes an open-instance delegate over an interface method, then run under R2R on wasm:

interface IGetInt { int GetInt(); }
struct MyStruct : IGetInt { public int a; public int GetInt() => a; }
delegate int D(IGetInt arg);
static int Main()
{
    var s = new MyStruct { a = 42 };
    var mi = typeof(IGetInt).GetMethod("GetInt");
    var func = (D)mi.CreateDelegate(typeof(D)); // open-instance delegate
    return func(s) == 42 ? 100 : 1;
}

JIT/Regression Runtime_79354 reproduces it when crossgen'd to R2R.

Expected behavior

Open-instance delegate invoke over a virtual/interface method returns correctly under R2R (exit 100), matching the interpreter.

Actual behavior

RuntimeError: memory access out of bounds (release) / NullReferenceException (checked) inside the interpreter's INTOP_CALLDELEGATE open-virtual dispatch, from a mis-located receiver.

Regression?

No — new R2R-on-wasm bring-up path.

Known Workarounds

Run the test method without ReadyToRun (DOTNET_ReadyToRun=0), or use a closed delegate.

Configuration

CoreCLR, browser-wasm / wasi-wasm, FEATURE_PORTABLE_ENTRYPOINTS + interpreter, ReadyToRun enabled (calling method R2R-compiled).

Other information

Fix direction (for the interpreter/bridge owner): reconcile the INTOP_CALLDELEGATE open-virtual arg-shuffle sizing (ip[4]/ip[5]) and receiver slot (callArgsOffset + INTERP_STACK_SLOT_SIZE) with the argument layout produced by the R2R→interpreter thunk marshalling, so the receiver lands where line 3399 reads it. Exact faulting field (receiver offset vs shuffle size) pending a checked-crossgen runtime read. Related: #130634 (R2R↔interpreter bridge trap family).

Note

This issue was authored with the assistance of GitHub Copilot.

Activity

  1. lewing
    added
    arch-wasmWebAssembly architecture
    area-VM-coreclr
    on Jul 16, 2026
  2. github-project-automation
    added this to AppModelon Jul 16, 2026

  3. dotnet-policy-service commented on Jul 16, 2026

    @dotnet-policy-service
    dotnet-policy-serviceBot
    on Jul 16, 2026 – with Dotnet Policy Service
    Contributor

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

  4. dotnet-policy-service
    added
    untriagedNew issue has not been triaged by the area owner
    on Jul 16, 2026

  5. dotnet-policy-service commented on Jul 16, 2026

    @dotnet-policy-service
    dotnet-policy-serviceBot
    on Jul 16, 2026 – with Dotnet Policy Service
    Contributor

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

  6. oroztocil
    added this to the 11.0.0 milestone on Jul 16, 2026
  7. oroztocil
    removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 16, 2026
  8. oroztocil
    assigned
    lewing
    on Jul 16, 2026

  9. lewing commented on Jul 16, 2026

    @lewing
    lewing
    on Jul 16, 2026
    MemberAuthor

    cc @dotnet/wasm-contrib

  10. alexyakunin commented on Jul 31, 2026

    @alexyakunin
    alexyakunin
    on Jul 31, 2026

    Not wasm-specific — we hit the same fault on iOS arm64 (CoreCLR + composite R2R + interpreter), so the arch-wasm label may be too narrow.

    Config: .NET 11 preview 6 (11.0.0-preview.6.26359.118), net11.0-ios / ios-arm64, iOS 26.5 device, MAUI Blazor Hybrid app, Release, composite ReadyToRun, UseInterpreter=true.

    Our trigger is the same construct as the repro in the description — an open-instance delegate over an interface method, created via CreateDelegate with no target and invoked from R2R-compiled code:

    public interface IHasMetadata {
    MetadataBag Metadata { get; init; }
}

// Action<IHasMetadata, MetadataBag> — open-instance delegate over an interface setter
typeof(IHasMetadata).GetProperty("Metadata")!.SetMethod!
    .CreateDelegate(typeof(Action<IHasMetadata, MetadataBag>));

    The arm64 stack, faulting in the open-virtual dispatch beneath interpreted frames, with R2R frames below:

    libcoreclr   TypeString::AppendMethodImpl(...)
libcoreclr   CallStackLogger::PrintStackTrace(...)
libcoreclr   LogInfoForFatalError(...)
libcoreclr   EEPolicy::LogManagedCallstackForSignal(...)
libcoreclr   invoke_previous_action(...)
libsystem_platform.dylib  _sigtramp
libcoreclr   CID_VirtualOpenDelegateDispatchWorker      <-- fault
libcoreclr   CID_VirtualOpenDelegateDispatch
libcoreclr   CallJittedMethodRetVoid
libcoreclr   InvokeCalliStub(CalliStubParam*)
libcoreclr   InterpExecMethod(...)
libcoreclr   ExecuteInterpretedMethod
libcoreclr   InterpreterStubRetVoid
<app>.r2r    0xe62f6c                                   <-- R2R-compiled caller

    Secondary issue, possibly worth separating: on iOS this never presents as a crash. EEPolicy::LogManagedCallstackForSignal symbolicating the managed stack on-device outlasts iOS's 5s watchdog, so the process is killed with 0x8BADF00D ("Failed to terminate gracefully after 5.0s", WatchdogVisibility: Foreground) while stuck in TypeString::AppendMethodImpl. Four consecutive occurrences, always thread 0. To the user the app paints its UI and then silently stops responding to touch, with nothing in the app's own logs — considerably harder to attribute than a plain SIGSEGV. A variant shows PAL_DispatchException → cthread_yield.

    Workaround: don't enable the interpreter. Note this is coupled on Apple targets: with UseInterpreter/MtouchInterpreter unset the macios SDK sets DynamicCodeSupport=false, so RuntimeFeature.IsDynamicCodeSupported goes false and anything relying on runtime codegen (for us, MessagePack's DynamicObjectResolver) stops working too. So on iOS today the choice is effectively "interpreter and this crash" or "no dynamic code at all".

    No minimal standalone repro from us — field report from a large app, and the description already pins the root cause. Happy to pull further diagnostics off the device if the arm64 path is useful.

  11. alexyakunin
    added 4 commits that reference this issue on Jul 31, 2026

    fix(reflection): avoid open-instance delegates over virtual accessors…

    69e2d57

    chore: upgrade Fusion 14.2.45 -> 14.2.50

    842902a

    fix(ios): re-enable the interpreter, with Blazor excluded from R2R

    a8d951a

    fix(ui): assign VirtualList parameters directly instead of via Blazor

    9f1384c
  12. jkotas
    added
    os-iosApple iOS
    on Jul 31, 2026

  13. dotnet-policy-service commented on Jul 31, 2026

    @dotnet-policy-service
    dotnet-policy-serviceBot
    on Jul 31, 2026 – with Dotnet Policy Service
    Contributor

    Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
    See info in area-owners.md if you want to be subscribed.

  14. jkotas
    added
    area-CodeGen-Interpreter-coreclr
    and removed
    area-VM-coreclr
    on Jul 31, 2026

  15. dotnet-policy-service commented on Jul 31, 2026

    @dotnet-policy-service
    dotnet-policy-serviceBot
    on Jul 31, 2026 – with Dotnet Policy Service
    Contributor

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

  16. kotlarmilos
    modified the milestones: 11.0.0, 12.0.0 on Aug 3, 2026
  17. lewing
    added a commit that references this issue on Sep 28, 2026

    [wasm][R2R] Re-enable open virtual delegate runtime tests (#134765)

    9b01df7
  18. lewing
    closed this as completedin #134765on Sep 28, 2026
  19. alexyakunin
    added a commit that references this issue on Oct 16, 2026

    Revert "feat(ios): allow dynamic code on iOS, to see how the app beha…

    9cdd4c6
  20. github-actions
    locked and limited conversation to collaborators on Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

arch-wasmWebAssembly architecturearea-CodeGen-Interpreter-coreclros-iosApple iOS

Type

No type

Projects

  • AppModel
    Status
    No status

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions