[mono] Pass the pending exception correctly from interp_runtime_invok… #72126
Conversation
ghost
assigned 
|
/azp run runtime-wasm |
|
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis Issue Details…e (). Fixes #71838.
|
|
Azure Pipelines successfully started running 1 pipeline(s). |
vargaz
added
arch-wasm
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -2119,13 +2119,13 @@ interp_runtime_invoke (MonoMethod *method, void *obj, void **params, MonoObject | |||
|
|
|||
| context->stack_pointer = (guchar*)sp; | |||
|
|
|||
| check_pending_unwind (context); | |||
There was a problem hiding this comment.
Do you also need to change interp_entry ?
There was a problem hiding this comment.
check_pending_unwind seems dubious to me. It throws a C++ exception, but this is only caught in llvmonly code. This code probably needs some refactoring.
I think the intended behavior for check_pending_unwind should be
if (mono_aot_mode == MONO_AOT_MODE_LLVMONLY_INTERP && context->has_resume_state)
mono_llvm_cpp_throw_exception ();
Additionally, when exiting the interpreter (returning from interp_entry, interp_entry_from_trampoline, interp_runtime_invoke) we probably should assert !context->has_resume_state, because if we have resume state here it means we are in non-llvmonly mode where we resume directly to the ip of the handling code. When returning to EH (interp_run_finally ...) we can probably assert that we have context->handler_frame set if we have resume state, since otherwise we should have resumed already)
Maybe we should have 2 check_pending_unwind methods, one for returning to compiled/native and the other for returning to EH since their behavior is quite different.
There was a problem hiding this comment.
The !context->handler_frame check can only be true in mixed mode.
…e ().
Fixes #71838.