[mono][interp] Fix invocation of finally clauses with tiering enabled #69909
Conversation
When unwinding the stack during EH, we first populate a StackFrameInfo with various data, like native_offset and jinfo. Let's assume this data is for an untiered method. If this frame has multiple finally clauses that need to be invoked, a finally invocation could tier up the InterpFrame that it is executing. The future finally invocations would use the IPs from the previously resolved untiered method. This change makes the interpreter receive only the clause index (in interp_run_finally) so we correctly resolve the native offsets of the handler.
|
Tagging subscribers to this area: @BrzVlad Issue DetailsWhen unwinding the stack during EH, we first populate a StackFrameInfo with various data, like native_offset and jinfo. Let's assume this data is for an untiered method. If this frame has multiple finally clauses that need to be invoked, a finally invocation could tier up the InterpFrame that it is executing. The future finally invocations would use the IPs from the previously resolved untiered method. This change makes the interpreter receive only the clause index (in interp_run_finally) so we correctly resolve the native offsets of the handler. Fixes #69868, maybe also #69864
|
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Could I get a review on this, since it fixes CI failures. |
|
There is no need to backport this as we shouldn't have tiering enabled on preview5. I closed the issues, but keep eyes open for any suspect interp crashes and point them over to me. |
ghost
locked as resolved and limited conversation to collaborators
3 participants
When unwinding the stack during EH, we first populate a StackFrameInfo with various data, like native_offset and jinfo. Let's assume this data is for an untiered method. If this frame has multiple finally clauses that need to be invoked, a finally invocation could tier up the InterpFrame that it is executing. The future finally invocations would use the IPs from the previously resolved untiered method. This change makes the interpreter receive only the clause index (in interp_run_finally) so we correctly resolve the native offsets of the handler.
Fixes #69868, maybe also #69864