[wasm] Restrict enclosing-try throw-helper attach to the same funclet by lewing · Pull Request #131279 · dotnet/runtime

lewing · 2026-07-23T17:22:29Z

[wasm] Restrict enclosing-try throw-helper attach to the same funclet

Problem

crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal end opcode (0x0b) is dropped for an EH funclet, so wasm-tools validate (and V8) reject the module with "function body must end with end opcode". A related symptom is a miscomputed branch target depth in the same funclet (tracked as #131252).

Root cause

The defect is in wasm block layout, in FgWasm::VisitWasmSuccs (src/coreclr/jit/fgwasm.h).

#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is KD_TRY, the helper is also attached as a successor if

comp->bbInTryRegions(key.RegionIndex(), block)

is true. bbInTryRegions is a purely lexical try-nesting test — it does not check that the throw helper and the side-entry live in the same function region (funclet).

So a throw helper for an outer try region that belongs to the main method can be attached to a catch-resumption side-entry (BBF_CATCH_RESUMPTION) that merely nests inside that try but physically lives in a handler funclet. RPO layout then lays the main-method helper inside the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal end and corrupts its branch target depths.

Concrete trace from System.Data.DataColumn:set_Expression (instrumented VisitWasmSuccs, deduped):

sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1
sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1

BB76 is the throw helper for root try region #4 (KD_TRY, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3.

This is an ordinary catch-resumption EH shape (async=0); it is independent of runtime-async, and fgwasm.h is byte-identical to main. It is latent on main only because R2R-wasm codegen isn't enabled there yet.

Fix

Gate the enclosing-try relaxation on same-function-region ownership. A new funcRegionOf lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors funGetFuncIdx but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region:

if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk)))
{
    RETURN_ON_ABORT(func(acd->acdDstBlk));
}

The exact-match path (a helper keyed to the block's own region) is unchanged, and #130945's intended case (an inner-try side-entry pulling its enclosing try's helper within the same funclet) still matches — so this only removes the cross-funclet edge.

Validation

Standalone System.Data.Common R2R wasm crossgen, release JIT, wasm-tools validate (only fgwasm.h differs between runs):

	`wasm-tools validate`
baseline (`origin/main` layout)	`func 597 failed to validate` ❌
with this fix	passes ✅

Notes

Supersedes [wasm] Emit terminal end for EH funclets ending in a no-return call #131251, which hardened the terminal-end emission (the effect); this fixes the cause in layout. Closing [wasm] Emit terminal end for EH funclets ending in a no-return call #131251 in favor of this.
Related: Wasm / R2R: malformed wasm (missing function-body end opcode) for try / throwing-finally pattern in b51875 #129335 (incomplete predecessor for this defect class, do not reopen); [Wasm RyuJit] fix throw helper layout for side try entries in enclosed regions #130945 (introduced the lexical enclosing-try match); [wasm] crossgen2 ships an invalid branch depth (~0) for EH funclets whose branch target isn't on the wasm control-flow stack #131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix).
Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module.

Note

This change was authored with the assistance of GitHub Copilot.

VisitWasmSuccs (added in dotnet#130945) makes a throw helper a successor of a try side-entry whenever the helper's keyed try region lexically encloses the side-entry (bbInTryRegions). bbInTryRegions is a purely lexical try-nesting test: it does not check that the helper and the side-entry live in the same function region (funclet). As a result a main-method throw helper for an outer try can be attached to a catch-resumption side-entry that merely nests inside that try but lives in a handler funclet. RPO layout then places the main-method helper inside the funclet, interleaving it with funclet blocks. That corrupts the emitted wasm: the funclet's terminal `end` is dropped (module fails "function body must end with end opcode") and branch target depths are miscomputed. Gate the enclosing-try relaxation on same-function-region ownership: only attach the helper when funcRegionOf(block) == funcRegionOf(acd->acdDstBlk). funcRegionOf mirrors funGetFuncIdx but works for an arbitrary block and distinguishes a filter funclet from its filter-handler. The exact-match path (the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper within the same funclet) still matches. Verified on a standalone System.Data.Common R2R wasm crossgen (release JIT, without the end-emission change from dotnet#131251): baseline emits an invalid module (func 597 fails to validate); with this fix the module validates. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

…ix-wasm-funclet-layout

azure-pipelines · 2026-07-23T17:23:18Z

Azure Pipelines: Successfully started running 6 pipeline(s). 10 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

dotnet-policy-service · 2026-07-23T17:23:36Z

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

Copilot

Pull request overview

This PR adjusts WebAssembly (wasm32) flow-graph successor enumeration to avoid introducing cross-funclet edges when attaching throw-helper “ACD” blocks for enclosing try regions. The change is aimed at preventing block layout interleaving across funclet boundaries, which can corrupt wasm function bodies.

Changes:

Add a local funcRegionOf helper to compute the physical function-region (funclet) index for an arbitrary block, including distinguishing filter vs. filter-handler regions.
Track whether an ACD match came specifically from the enclosing-try relaxation (viaEnclosingTry).
Gate the enclosing-try successor attachment so the throw helper is only attached when it belongs to the same function region as the side-entry.

lewing · 2026-07-23T17:32:42Z

Validation: full input-set survey

Ran the entire 194-assembly input set as standalone crossgen2 R2R-wasm under the failing SIMD-forced config (--targetos:browser --targetarch:wasm --codegenopt:JitWasmSimdNyiToR2RUnsupported=0), baseline JIT vs. this fix, validating each module with wasm-tools validate:

	valid	invalid wasm	unrelated crossgen error
baseline (no fix)	191	2 — `System.Data.Common`, `System.Threading.Tasks.Parallel`	1
this fix	193	0	1

Fixes exactly the two invalid modules; all 191 previously-valid modules stay valid — 0 regressions, consistent with the change only narrowing cross-funclet throw-helper edges.
System.Threading.Tasks.Parallel is the module behind [wasm] crossgen2 ships an invalid branch depth (~0) for EH funclets whose branch target isn't on the wasm control-flow stack #131252 (miscomputed branch-target depth on the same corrupted funclet layout); it validates with this fix, so [wasm] crossgen2 ships an invalid branch depth (~0) for EH funclets whose branch target isn't on the wasm control-flow stack #131252 is subsumed here — no separate change needed.
The lone remaining non-pass (xunit.runner.utility) is a pre-existing, unrelated crossgen NotImplementedException: System.Reflection.MemberInfo, identical with and without this fix.

Note

This comment was authored with the assistance of GitHub Copilot.

…ix-wasm-funclet-layout

…nclosingTry Andy Ayers' review on dotnet#131279: 1. Extract the local funcRegionOf lambda in VisitWasmSuccs into a reusable Compiler::bbIsInSameFunclet(BasicBlock*, BasicBlock*) predicate (declared in compiler.h beside funGetFuncIdx, inline definition in compiler.hpp). It mirrors funGetFuncIdx but is valid for an arbitrary (non-entry) block and distinguishes a filter funclet from its filter-handler. 2. Drop the viaEnclosingTry guard and gate every match on bbIsInSameFunclet unconditionally. viaEnclosingTry restricted the same-funclet check to the enclosing-try relaxation only, out of blast-radius conservatism. A 194-assembly R2R-wasm crossgen A/B (guarded vs. unconditional) produced byte-identical output on all 193 emitted modules with zero new invalid modules or crossgen failures, so the guard never changed a direct-match outcome. Gating direct matches on same-funclet too is strictly more correct: a direct match naming a cross-funclet helper is exactly the mis-layout this fix prevents. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

The helper is documented as valid only after funclets are created; assert it like funGetFunc/funGetFuncIdx do, to catch misuse early instead of silently returning region 0 for blocks with unset funclet metadata. The sole caller (VisitWasmSuccs, in PHASE_WASM_CONTROL_FLOW) runs long after PHASE_CREATE_FUNCLETS, so the invariant always holds. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

AndyAyersMS

Thanks for fixing this!

…on branch (#131287) Fixes #131285 ## Problem On WebAssembly R2R (crossgen), an `async` method with a `try { ...; return; } catch { }` where the `try` completes normally by branching out early (a `return` after an `await`) generates a **valid** wasm module that **traps at runtime** with `RuntimeError: unreachable` on the normal-completion path. This is distinct from #131279 (dropped terminal `end` → *invalid* module) and is not a reopening of #129335 — here the module is well-formed and validates; it simply traps at runtime. ## Root cause In `Compiler::fgWasmControlFlow()`, a non-contiguous forward branch that exits a try/catch region started its enclosing wasm `Block` at the **innermost** try's begin. When the branch also escapes an **outer** catch-try that shares the same end cursor — the wasm catch-resumption / resume-after-catch shape, where the paired `ExnRefWrapper` is stretched past the try-end to cover the resumption dispatcher — the `Block` ends up nested *inside* that outer try. The normal-completion branch then resolves to depth 0 and lands on the outer try's trailing validation `unreachable` (emitted right after its `end` by `genEmitStartBlock`) instead of the continuation. ## Fix Walk the enclosing try regions outward and start the `Block` at the **outermost** escaped catch-try's begin, so the `Block` encloses those trys' ends and the branch resolves to the continuation (`br 0` → `br 1`). For a single-level `try/catch` the outermost escaped region is also the innermost, so behavior there is unchanged. ## Test Adds `src/tests/JIT/Regression/JitBlue/Runtime_131285`, a sync `[Fact]` that drives an `async Task` `MoveNext` through the normal-completion `return` path. The csproj sets `<AlwaysUseCrossGen2 Condition="'$(TargetOS)' == 'browser'">true</AlwaysUseCrossGen2>` so the browser leg is actually compiled to wasm R2R and run under node — without it a plain browser leg runs the test as ordinary JIT and silently false-passes. ## Validation - Runtime A/B on the exact CLRTest node command: unfixed JIT traps (`exit=1`), fixed JIT passes (`exit=100`). - Composite-mode crossgen A/B: unfixed emits trapping `br 0`, fixed emits `br 1`. - 194-assembly sweep: 0 new invalid modules, 185 byte-identical; single-level try/catch provably unaffected. > [!NOTE] > This pull request was generated with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 964b4f25-1c41-44d6-81fb-a6a75ee7d3e4

lewing · 2026-07-23T23:02:17Z

/ba-g osx checked build completed successfully but infra is stuck

lewing and others added 3 commits July 23, 2026 12:13

Merge commit 'cba95874fc4613b7325f2ad650da783768fe27cc' into lewing-f…

1773a0a

…ix-wasm-funclet-layout

Merge commit 'e7354b62dd16cd9c3e67107cfacd98cea8acadbe' into lewing-f…

010fad3

…ix-wasm-funclet-layout

Copilot AI review requested due to automatic review settings July 23, 2026 17:22

lewing mentioned this pull request Jul 23, 2026

[wasm] Emit terminal end for EH funclets ending in a no-return call #131251

Closed

github-actions Bot added the area-VM-coreclr label Jul 23, 2026

dotnet-policy-service Bot assigned lewing Jul 23, 2026

Copilot started reviewing on behalf of lewing July 23, 2026 17:23 View session

lewing requested a review from AndyAyersMS July 23, 2026 17:23

Copilot AI reviewed Jul 23, 2026

View reviewed changes

lewing mentioned this pull request Jul 23, 2026

[wasm] crossgen2 ships an invalid branch depth (~0) for EH funclets whose branch target isn't on the wasm control-flow stack #131252

Closed

lewing requested a review from davidwrighton July 23, 2026 17:34

lewing added 2 commits July 23, 2026 12:53

Merge commit '21423880dc08193fa3e20d258d49318d0e123ff2' into lewing-f…

1c904b9

…ix-wasm-funclet-layout

Merge commit '9e503504508329338dd7fffafb326e15caae92a7' into lewing-f…

28d27b7

…ix-wasm-funclet-layout

AndyAyersMS requested changes Jul 23, 2026

View reviewed changes

Comment thread src/coreclr/jit/fgwasm.h Outdated

Comment thread src/coreclr/jit/fgwasm.h Outdated

Merge commit '54549c8df1cdbd7b373b56a53104439e75bcfcbd' into lewing-f…

9bc1db2

…ix-wasm-funclet-layout

This was referenced Jul 23, 2026

[wasm] R2R codegen: async try/return/catch MoveNext traps at runtime (RuntimeError: unreachable) on normal-completion branch #131285

Closed

[wasm] Fix R2R codegen trap on async try/return/catch normal-completion branch #131287

Merged

Copilot AI review requested due to automatic review settings July 23, 2026 19:27

Copilot started reviewing on behalf of lewing July 23, 2026 19:28 View session

Copilot AI reviewed Jul 23, 2026

View reviewed changes

Comment thread src/coreclr/jit/compiler.hpp

Copilot AI review requested due to automatic review settings July 23, 2026 19:42

Copilot started reviewing on behalf of lewing July 23, 2026 19:42 View session

Copilot AI reviewed Jul 23, 2026

View reviewed changes

lewing requested a review from AndyAyersMS July 23, 2026 20:33

AndyAyersMS approved these changes Jul 23, 2026

View reviewed changes

lewing enabled auto-merge (squash) July 23, 2026 22:50

lewing merged commit 1ccd637 into dotnet:main Jul 23, 2026
131 of 136 checks passed

lewing deleted the lewing-fix-wasm-funclet-layout branch July 23, 2026 23:03

dotnet-maestro Bot mentioned this pull request Jul 24, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#7872

Merged

dotnet-milestone-bot Bot added this to the 11.0-rc1 milestone Jul 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[wasm] Restrict enclosing-try throw-helper attach to the same funclet#131279

[wasm] Restrict enclosing-try throw-helper attach to the same funclet#131279
lewing merged 8 commits into
dotnet:mainfrom
lewing:lewing-fix-wasm-funclet-layout

lewing commented Jul 23, 2026

Uh oh!

azure-pipelines Bot commented Jul 23, 2026

Uh oh!

dotnet-policy-service Bot commented Jul 23, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

lewing commented Jul 23, 2026

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

AndyAyersMS left a comment

Uh oh!

lewing commented Jul 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

lewing commented Jul 23, 2026

Problem

Root cause

Fix

Validation

Notes

Uh oh!

azure-pipelines Bot commented Jul 23, 2026

Uh oh!

dotnet-policy-service Bot commented Jul 23, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

lewing commented Jul 23, 2026

Validation: full input-set survey

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

lewing commented Jul 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants