crossgen2 wasm: invalid catch emitted for async/await state machine (R2R module fails wasm validation)

[pavelsavara]

Description

crossgen2's WebAssembly backend emits an invalid catch instruction for the C# async/await state machine. When an assembly containing any async method is cross-compiled to ReadyToRun for browser-wasm, the resulting R2R wasm module fails wasm decoding/validation, so the browser (and V8/d8/Node) rejects it at module-compile time:

CompileError: WebAssembly.Module(): Compiling function #N failed:
catch kind generates 1 operand, target block expects 0

The plain IL build of the same code runs fine — only the R2R image is malformed.

This is the wasm exception-handling lowering of the compiler-generated MoveNext: the C# compiler wraps the async method body in a try/catch (to forward the exception to AsyncTaskMethodBuilder.SetException), and crossgen2 lowers that catch to a wasm catch whose operand arity doesn't match the enclosing block's expected type.

Minimal repro

A single async method is enough — no user-level try/catch is required:

using System.Runtime.CompilerServices;
using System.Threading.Tasks;

public static class Test
{
    public static async Task<int> Main()
    {
        return await AsyncYield(1);
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static async Task<int> AsyncYield(int input)
    {
        await Task.Yield();
        return input * 2;
    }
}

Cross-compile to R2R for wasm, then load the produced module in any wasm engine.

The crossgen2 invocation used (from the in-tree WebAssembly SDK R2R hook):

crossgen2 @<rsp> --targetarch:wasm --targetos:browser --obj-format:wasm \
    --jitpath:<clrjit_wasm> --codegenopt:JitWasmNyiToR2RUnsupported=1 -O \
    --out:<app>.wasm <app>.dll

Validate the raw crossgen output directly (no runtime needed — it's a decode/validation failure) with d8/V8:

const bytes = new Uint8Array(readbuffer("App.wasm"));
try { new WebAssembly.Module(bytes); print("COMPILE OK"); }
catch (e) { print("COMPILE FAILED: " + e); }

Observed:

COMPILE FAILED: CompileError: WebAssembly.Module(): Compiling function #5 failed:
catch kind generates 1 operand, target block expects 0 @+4435

(V8 15.1.103.)

What works vs. what fails

Cross-compiled to R2R for wasm, the following synchronous EH shapes all validate and run fine:

• plain try/catch
• try/finally
• try/catch/finally
• catch (…) when (filter)
• throw; rethrow
• nested try/catch
• catch { } (no exception variable)

Only the async state machine MoveNext produces the invalid catch.

Expected

crossgen2 should emit a valid wasm catch for the async-state-machine try/catch, so R2R images containing async methods load in wasm engines.

Actual

The R2R wasm module fails to compile/validate with catch kind generates 1 operand, target block expects 0.

Environment

• dotnet/runtime main
• Target: browser-wasm, CoreCLR, Debug
• crossgen2 wasm backend (--obj-format:wasm, clrjit wasm codegen)

Note

This issue was authored with the assistance of GitHub Copilot.

[dotnet-policy-service]

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

[dotnet-policy-service]

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

[AndyAyersMS]

This is fixed by the catch_ref depth fix in PR #129716 (commit 0c5db85). The C# compiler's async state machine wraps MoveNext in try/catch (Exception) that converts caught exceptions into AsyncTaskMethodBuilder.SetException calls; that shape exercises the wasm EH lowering path where a plain block sits between the catch wrapper and the try_table, and the JIT was hard-coding catch_ref to depth 0 (innermost) which incorrectly targets the plain block instead of the exnref wrapper — producing "catch kind generates 1 operand, target block expects 0".

Verified locally with the minimal repro from this issue: crossgen2 output now passes wasm-validate --enable-exceptions --enable-tail-call.

Note

This comment was generated by GitHub Copilot.