[mono] Keep in-flight exception alive across LLVM resume unwind

[pavelsavara]

Summary

When an exception is unwound through an LLVM-compiled finally/fault handler under full-AOT, mono_handle_exception_internal saves the resume state and transfers control to the managed handler, which later calls back into mono_resume_unwind to continue unwinding. The in-flight exception object was stored across that window in ResumeState.ex_obj as a raw pointer, explicitly marked /* FIXME: GC */:

jit_tls->resume_state.ex_obj = obj;

The managed handler can reach a GC safepoint (for example the Monitor.Exit call emitted into a synchronized method wrapper). A moving GC then relocates the exception object, leaving ex_obj stale. When mono_resume_unwind resumes and passes that pointer to mono_object_isinst_checked while searching for a matching catch clause, it dereferences a garbage MonoClass:

SIGSEGV
  mono_class_is_assignable_from_internal
  mono_object_isinst_checked
  ... (second-pass catch search)
  llvm_resume_unwind_trampoline

This reproduces intermittently under load (multiple threads throwing/catching while allocating), and only with the LLVM full-AOT unwinder ΓÇö the llvmonly catch path already keeps the exception alive via a pinned GC handle (ResumeState.ex_gchandle), and the JIT uses a different unwind mechanism.

Fix

Store the in-flight exception in a pinned GC handle (ex_gchandle) across the LLVM resume window, mirroring the existing llvmonly catch path, and read it back in mono_resume_unwind. The now-unused raw ex_obj field is removed from ResumeState.

Testing

Re-enables JIT/Regression/CLR-x86-JIT/V1.1-M1-Beta1/b143840 on Mono (the [ActiveIssue] annotation is removed so CI exercises the fix). Validated with an x64 Mono LLVM full-AOT build: the test crashed ~17% of runs (5/30) before the change and 0 / 300 runs after it, with JIT mode unaffected.

Note

This change was authored with the assistance of GitHub Copilot.

---

Part of the MonoAOT LLVM 23 full-AOT regression set tracked by #129508. Built and tested together with the Emscripten 5.0.6 / LLVM 23 bump on #129396, where the re-enabled b143840 test passes on the runtime-llvm AllSubsets_Mono_LLVMFULLAOT_RuntimeTests leg.

Contributes to #129508.

[Copilot]

Pull request overview

Updates Mono’s LLVM full-AOT exception resume plumbing to keep the in-flight exception reachable across the managed finally/fault window by storing it in ResumeState as a GCHandle (and retrieving it in mono_resume_unwind), and re-enables a regression test previously skipped on Mono.

Changes:

• Remove the raw ResumeState.ex_obj field and rely on ResumeState.ex_gchandle for keeping the exception alive across the LLVM resume window.
• In mono_handle_exception_internal, allocate/free the resume-state GCHandle when unwinding through LLVM-compiled finally/fault; in mono_resume_unwind, retrieve the exception from the handle and free it before continuing unwinding.
• Re-enable b143840 on Mono by removing the ActiveIssue skip annotation in the IL test.

Reviewed changes

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

File	Description
src/tests/JIT/Regression/CLR-x86-JIT/V1.1-M1-Beta1/b143840/b143840.il	Unskips the regression test on Mono by removing ActiveIssue.
src/mono/mono/mini/mini-runtime.h	Removes the raw exception pointer field from ResumeState, leaving GCHandle-based storage.
src/mono/mono/mini/mini-exceptions.c	Stores the in-flight exception in a GCHandle during LLVM finally/fault unwinding and retrieves it in mono_resume_unwind.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

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

[pavelsavara]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vitek-karas]

Looks good - thanks!

[akoeplinger]

The Regression_o_2 failure in runtime-extra-platforms (Build linux-x64 Release AllSubsets_Mono_MiniFullAot_RuntimeTests minifullaot) is most likely unrelated, I've seen it fail in main too

[pavelsavara]

/ba-g unrelated failures