[pcshrosbree]

Thread::ReadyForAsyncException refuses to raise a thread abort inside a finally or catch handler. Its walk, TAStackCrawlCallBackWorker, moves the offset of every non-active frame back by one before comparing it with the EH clauses, because the frame's control PC is a return address.

On wasm, the control PC of a ReadyToRun frame is a virtual IP instead. fgWasmVirtualIP gives each region of a method a number and stores the current region's number in the frame before each call. A new region starts at every try, handler and filter boundary, so every call in the first region of a handler reports exactly the handler's start. Moved back by one, that is the previous region, outside the handler. With the default ReadyToRun CoreLib, ControlledExecution.Run then gets the abort raised again inside its own finally and catch (ThreadAbortException) handlers, at their first call through an import cell, and throws ThreadAbortException instead of OperationCanceledException.

SfiInit and SfiNext already skip the adjustment for virtual IPs. This change does the same in TAStackCrawlCallBackWorker. A virtual IP never needs the adjustment: it names the region of the call in progress, and EH boundaries are region boundaries. For this walk, which checks only handler ranges, the adjustment changes the answer only at a handler's first region, where it is wrong; crossing a try boundary does not change handler membership. Active frames were never adjusted. Interpreter frames are not virtual IPs and keep the adjustment.

The second commit lets the ControlledExecutionTests that need no second thread run on the single-threaded wasm legs. The whole class was conditioned on IsMultithreadingSupported, so none of it ran there. The condition is now on the four tests that cancel from Task.Run. CancelBeforeRun covers this fix. #135520 re-enables CancelInTryAndExitCatchNormally, which also uses Task.Run; whichever of the two lands second needs to add the condition to it.

Measured with browser-wasm Checked builds under node, single-threaded, default ReadyToRun CoreLib, using a program with the same shapes as the tests:

case	main 3994df1ceee1	this PR
CancelBeforeRun (token cancelled before Run)	the interpreter's #135463 assert in the caller's catch, before it reports the exception type	OperationCanceledException
action with no handler, thread aborts itself through Canceler.Cancel	ThreadAbortException	OperationCanceledException
action with only try/finally, same	ThreadAbortException, finally ran	OperationCanceledException, finally ran
CancelItselfFromFinally	passes	passes
any of these with DOTNET_ReadyToRun=0	unchanged	unchanged

On linux-x64, osx-arm64 and windows-x64 (Checked), the runtime's code differs from main only in line-number constants after the change. On linux-x64, restoring the original line numbers makes the code identical to main. On osx-arm64 and windows-x64, it is identical to a control with the wasm-only lines removed and their line positions retained. ControlledExecutionTests passes 8/8 on all three with the test change. I did not run the library tests on wasm locally or test a Release runtime.

This fixes the first problem in #135914. Token cancellation from inside Run still reaches the second problem: after CTS's ReadyToRun catch, the end-of-catch abort check asserts on wasm in Checked builds. I'm asking there how you'd like it done.

Partially addresses #135914 (the second problem stays open there).

Note

This PR was prepared with AI assistance (Anthropic Claude, checked by OpenAI Codex) at my request. I reviewed the change, the test and the measurements before opening it.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 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]

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

[lewing]

/azp run runtime-coreclr outer loop

[azure-pipelines]

No pipelines are associated with this pull request.

[lewing]

thanks for tracking down the misclassification here

[pcshrosbree]

@jkotas lewing approved this, but Build Analysis is still red from the run on October 16. The check summary shows these unmatched failures:

• HalfEstimateR2R on linux-x64 Checked: The application to execute does not exist: .../r2rdump/r2rdump.dll.
• System.Text.Json.Tests on windows-x86 Checked: it crashed with the x86 epilog assert in x86: since #135793, localloc epilogs use mov esp, ebp, which the GC-info epilog decoder rejects (assert in SKIP_LEA_ESP_EBP) #136020. The fix, JIT: keep lea esp, [ebp] in x86 epilogs #136021, is approved but not yet merged.

Would you prefer a rerun, or /ba-g?

[pcshrosbree]

Thank you for the review and the merge.