[RuntimeAsync] Implement IL_ThrowExact for x86/funclets #3100
Conversation
|
If I try to define The way I "define" it is by adding unconditional
Am I doing it right? Is it supposed to work? |
There are at least three places that need to be patched up - filipnavara/runtime@5728708 |
|
Now simple async tests that do not do EH are passing, but EH test fails. This is something with exception dispatching. The change may not be as mechanical as copying the pattern from |
|
Okay, I will have a look tomorrow. (The funclets patch on top of main passed the tests this morning.) |
|
Nvm, I found the instructions. |
|
I initially compiled everything in Debug configuration and the
I don't think there's a problem with the implementation of |
|
FWIW I see the same failures even with the baseline (no funclets) in Debug builds. UPD: Checked runtime w/ Debug libs also fails: UPD2: I did a full rebuild, checked runtime + release libs, still fails with the assert above (without any of my changes). |
|
buildroslynnugets.bat is a prerequisite. It will build the nugets locally There are some tests that are not passing in the baseline on x86. Seems like something got broken recently. Even when we run tests, sometimes we miss things since there is no CI. async\simple-eh should be passing (passes when I run it) |
|
I think we should get all baseline tests to pass first. We are in a process of moving the code to main repo, so need to merge code back and forth to maintain some coherence of changes. It is a bit of a fragile state. It is temporary. I still suspect the IL_ThrowExact might need more changes than IL_Throw, since it is kind of rethrow of an exception that logically has not been thrown yet. |
Makes sense to me.
The changes are in the C part of the code. This PR modifies only how the initial context for the exception propagation gets captured. Unless there's a change to
The test passed for me both without funclets and with this change + funclet cherry-pick commit. I only tested the Debug build though. I got sidetracked by the other issues and didn't retest it in Release/Checked to see if it fails there. |
|
The problem with baseline seems have been resolved. #3101 |
|
Thanks, I will resume testing tomorrow. |
|
now, with the rebased PR, I see all async tests pass on x86, except for simple-eh. Same stack as before: public static async2 Task<int> Handler()
{
try
{
return await Throw(42);
}
catch (IntegerException ex)
{
return ex.Value;
}
}
[MethodImpl(MethodImplOptions.NoInlining)]
public static async2 Task<int> Throw(int value)
{
await Task.Yield();
throw new IntegerException(value);
}Something is not working. Note that I'll try to figure what part does not match up. |
|
Let me know if you find something but no need to waste too much time on it. I hope I will be able to reproduce it and debug it. |
|
It seems that it fails to find the handler in The part of the JIT dump that throws the exception: and reported EH table: |
|
Possible fix is to change There's a comment in |
|
Fix for the bug submitted upstream: dotnet/runtime#115065 |
|
Thanks @filipnavara ! I will try cherrypicking the upstream change. |
…ateContextFromTransitionBlock (#115065) This could lead to -1 offset inadvertently not applied in `SfiInit` for control PC. As a consequence a `throw` at the very last instruction of `try` block may not be matched correctly.
|
I have rebased the changes onto upstream/feature/async2-experiment and added a commit from dotnet/runtime#115065 . With all that the async tests are passing on x86 regardless if |
ad96467
into
dotnet:feature/async2-experiment
No description provided.