[mono][interp] Remove an assertion.

[vargaz]

The assertion can be hit in normal usage on wasm when calling a catch clause inside a finally clause from interp_run_clause_with_il_state ().

Test case is TCErrorConditionWriter:var_21 () in the xml test suite.

[ghost]

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The assertion can be hit in normal usage on wasm when calling a catch clause inside a finally clause from interp_run_clause_with_il_state ().

Test case is TCErrorConditionWriter:var_21 () in the xml test suite.

Author:	vargaz
Assignees:	vargaz
Labels:	area-Codegen-Interpreter-mono
Milestone:	-

[vargaz]

Re:
#78358

[vargaz]

This will need a backport to 7.0.

[vargaz]

The failure was only hit on 7.0 due to:
#78595

[vargaz]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[BrzVlad]

I don't understand the behavior with this change.

Let's say we have a method like this:

block1;
try {
    block2;
} finally {
    try {
        block3;
    } catch {
        block4;
    }
    block5;
}
block6;

So from your description, I assume that block1, block2, block3 are executed by AOT. Within block3 there is a throw so we then pass execution to interpreter. AOT expects interp_run_clause_with_il_state to run the method until the end and then just return to parent method were execution continues normally in AOT code.

Interpreter will start executing block4, and within block5 it encounters MINT_ENDFINALLY opcode. In interpreter, finally blocks are called by MINT_CALL_HANDLER which writes the leave address. Since block2 wasn't executed by interpreter, the endfinally leave address (which is block6) is not written (with current implementation sounds like it could even be junk). This means that we currently just silently return execution out of interpreter without ever executing block6.

@vargaz Is this correct ?

[jandupej]

I don't understand the behavior with this change.

Let's say we have a method like this:

block1;
try {
    block2;
} finally {
    try {
        block3;
    } catch {
        block4;
    }
    block5;
}
block6;

So from your description, I assume that block1, block2, block3 are executed by AOT. Within block3 there is a throw so we then pass execution to interpreter. AOT expects interp_run_clause_with_il_state to run the method until the end and then just return to parent method were execution continues normally in AOT code.

Interpreter will start executing block4, and within block5 it encounters MINT_ENDFINALLY opcode. In interpreter, finally blocks are called by MINT_CALL_HANDLER which writes the leave address. Since block2 wasn't executed by interpreter, the endfinally leave address (which is block6) is not written (with current implementation sounds like it could even be junk). This means that we currently just silently return execution out of interpreter without ever executing block6.

@vargaz Is this correct ?

@BrzVlad @vargaz Doesn't block5 just branch to start of block6?

[vargaz]

Yes, this might not be correct.

[BrzVlad]

@jandupej No, because the behavior is dependent on who executes this block. The finally block can be invoked as part of the method execution, when the guarded code is finished, or independently from EH. In which case the endfinally opcode (which has to be at the end of all finally blocks) just returns out of interp_exec_method

[vargaz]

Not the right fix, closing.