Uh oh!
There was an error while loading. Please reload this page.
[mono] Pass the pending exception correctly from interp_runtime_invok… - #72126
Conversation
vargaz
commented
Jul 13, 2022
/azp run runtime-wasm |
ghost
commented
Jul 13, 2022
Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
commented
Jul 13, 2022
vargaz
commented
Jul 14, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
vargaz
commented
Jul 14, 2022
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| 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.