[pcshrosbree]

Fixes #135463
Fixes #135871

This supersedes #135520, as @janvorli suggested there: the whole change in one PR, including the flip of the catch leave island.

• After an interpreted catch, InterpExecMethod raises a pending thread abort again at the resume point, as EECodeManager::ResumeAfterCatch does for compiled code. It sets up Thread::m_OSContext first, and it dispatches the abort from a try block of its own, outside the C++ catch of ResumeAfterCatchException.
• The flip: within a leave, every edge into a catch leave island now uses INTOP_LEAVE_CATCH; every other edge, including the final edge to the leave target, uses INTOP_BR. The catch therefore ends with INTOP_LEAVE_CATCH to its island. The resume point is then the island, which is inside every try region that encloses the catch's try region. The leave target need not be inside all of those regions, which is why the abort missed the enclosing catch in [Interpreter] A thread abort raised again after a catch skips the catch of the enclosing try #135871.
• The frame is marked faulting before the abort is raised, as for INTOP_THROW, so the handlers are looked up at the resume point itself rather than at the instruction before it.
• Tests: a new regression test, GitHub_135463, with seven cases. The two from [Interpreter] A thread abort raised again after a catch skips the catch of the enclosing try #135871 run only when the test is interpreted, because jitted code gets them wrong until ThreadAbortException raised again after a catch can skip a finally and reaches different handlers in tier-0 and optimized code #135637 is fixed. ControlledExecutionTests.CancelInTryAndExitCatchNormally is enabled again, and GitHub_135530 is no longer skipped under the interpreter.

I validated with Checked runtimes on linux-x64, osx-arm64 and windows-x64, built from main 24543dd with and without this PR. Both columns run this PR's tests; the main column runs them on main's runtime. The Regressions row is the exception: it compares each version's own runner. The results were the same on all three platforms.

	main	this PR
GitHub_135463, JIT	pass, #135871 cases skipped	pass, #135871 cases skipped
GitHub_135463, DOTNET_InterpMode 1/2/3, with and without TieredCompilation=0	process dies: assert in ReadyForAsyncException	pass
GitHub_135530, the same six interpreter configurations	fails (same assert)	pass
ControlledExecutionTests (9 tests), JIT / InterpMode 1, 2, 3	9 pass / process dies (same assert)	9 pass / 9 pass
Regressions merged runner, JIT and the six interpreter configurations		no new failures
JIT/interpreter, InterpMode 1 and 3	pass	pass

GitHub_135463 needs both the flip and the change that marks the frame faulting: without the flip, the two #135871 cases fail; without marking the frame faulting, the abort is caught by the same handler again and again, and the test hangs.

Note

This PR was prepared with AI assistance (Anthropic Claude, checked by OpenAI Codex) at my request. I reviewed it 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 this area: @JulieLeeMSFT, @BrzVlad, @janvorli
See info in area-owners.md if you want to be subscribed.

[pcshrosbree]

For context, here is where the related thread-abort work stands:

• Interpreted code on WASM: with this PR, the abort shapes from [Interpreter] Thread abort re-raised at the end of an interpreted catch: Thread::m_OSContext is not set up #135463 and [Interpreter] A thread abort raised again after a catch skips the catch of the enclosing try #135871 behave the same on wasi, browser WASM with ReadyToRun off, and linux-x64 with InterpMode 3. On main they hit the [Interpreter] Thread abort re-raised at the end of an interpreted catch: Thread::m_OSContext is not set up #135463 assert. I saw no difference in ordinary exception handling between main and this PR. The GitHub_135463 test itself is skipped on WASM because WASM is single-threaded.
• ReadyToRun code on browser WASM: the abort raised again after a catch still escapes ControlledExecution.Run ([wasm] Thread abort is raised inside finally and catch handlers of R2R code, so ControlledExecution.Run lets ThreadAbortException escape #135914). Do not adjust wasm virtual IPs in the thread abort stack walk #135915 fixes the first half, the virtual IPs in the abort stack walk. The second half, the end-of-catch abort check for ReadyToRun code, has a prototype but no PR yet. With this PR, Do not adjust wasm virtual IPs in the thread abort stack walk #135915 and that prototype together, all the browser cases pass.
• InterpMode 1: an abort raised again inside ReadyToRun CoreLib code called from interpreted code terminates the process with ResumeAfterCatchException ([Interpreter] ResumeAfterCatchException escapes ThrowControlForThread when compiled code raises a thread abort again and an interpreted frame catches it #135532), on main too. Draft [Interpreter] Install the resume-after-catch handler in ThrowControlForThread #135533 fixes it and is now stacked on this PR.

Note

This comment was prepared with AI assistance (Anthropic Claude, checked by OpenAI Codex) at my request. I reviewed it before posting it.

[janvorli]

LGTM, thank you!

[pcshrosbree]

@jkotas janvorli approved this, but Build Analysis is still red from the run on October 16. The CI failures I checked include:

• HttpClient certificate tests on Linux and Android.
• System.Threading test batches on browser-wasm and wasi-wasm.

JIT_r on browser-wasm checked matches the known issue #135966. Would you prefer a rerun, or /ba-g?

[pcshrosbree]

Thank you for the review and the merge.