Repository navigation
[Mono]: JIT/Methodical/eh/finallyexec/loopinfinally_do and JIT/Methodical/eh/finallyexec/loopinfinally_ro fails on Mono Windows. #65704
Description
Description
Mono runtime currently fails to execute the following CoreCLR runtime tests:
/JIT/Methodical/eh/finallyexec/loopinfinally_do/
JIT/Methodical/eh/finallyexec/loopinfinally_ro/
The tests uses the following construction:
finally
{
inside_finally:
Console.WriteLine("In finally, i = {0}", i);
i++;
if (i % 2 == 0) goto inside_finally;
}
When we lower this block we will add a save of RSP into RBP as well as sub size of param_area on platforms using it:
runtime/src/mono/mono/mini/mini-amd64.c
Line 5793 in 4b8bb2d
and when we leave the finally block we will restore RSP
runtime/src/mono/mono/mini/mini-amd64.c
Line 5808 in 4b8bb2d
The problem is when we jump, since we will jump back to start of BB, so we will continue to decrement RSP with param_area for each iteration, and that will crash when we exit the finally block (since it won't adjust for all decrements of RSP).
This is an issue on all platforms using an ABI that have a param_area that is larger than 0, currently true on Windows x64 using 32 byte param_area.
Issue detected when enabling CoreCLR runtime tests running on Mono Windows, #64281. As part of that PR, the tests have been disabled on Mono and marked with this issue for future tracking.
Reproduction Steps
Build and run individual runtime test on Windows Mono as described here, https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/mono/testing.md
Expected behavior
Following tests should pass:
/JIT/Methodical/eh/finallyexec/loopinfinally_do/
JIT/Methodical/eh/finallyexec/loopinfinally_ro/
Actual behavior
Following tests fails and have been disabled due to this issue:
/JIT/Methodical/eh/finallyexec/loopinfinally_do/
JIT/Methodical/eh/finallyexec/loopinfinally_ro/
Regression?
No, this has never worked on Mono.
Known Workarounds
No response
Configuration
No response
Other information
No response
Activity
lambdageek commentedon Jul 14, 2022
@lateralusX I tagged this one for 7, but maybe it's ok to push back to 8? the issue seems well-understood and I guess a fix might be to emit the handler preamble into a separate BB before the body of the finally clause so that branches back to the start of the finally do not re-execute it. not sure how easy that would be to do in method-to-ir.
lateralusX commentedon Jul 14, 2022
I think we can push it to 8, its a special case when using goto inside a finally clause and the solution is emitting two different basic blocks, one when entering the finally clause and the other that will be the goto target, but if I recalled correctly the change had some implications on the current logic so was not trivial to do, at least not when I decided to file the issue instead of fixing it right away.
SamMonoRT commentedon Aug 10, 2022
Moving to 8.0.0 and assigning to @lateralusX for tracking
Xinlong-Wu commentedon Jan 5, 2024
Hi, I got same problem on RISCV64 Arch. Do we have any progress on this issue?
cc: #96117
lateralusX commentedon Jan 8, 2024
Since we didn't hit this issue on official supported platforms (not depending on a param area like Win x64 ABI does) and since its a corner case, a fix has not been prioritized or planned (issue marked as future at the moment).