Infinite loop in Frame::UpdateFloatingPointRegisters on ARM64 #101921
Comments
dotnet-policy-service
bot
added
the
untriaged
rzikm
added
arch-arm64
os-windows
and removed
untriaged
|
Tagging subscribers to this area: @mangod9 |
|
seems consistent enough to me, I see a failure in the same tests every 12 hours in Kusto database (which I assume is the
|
|
Ok that's good to know, so looks related to new exception handling. Assigning to Jan. Should this be marked as affecting outerloop? |
|
This sounds like an unwind problem. This method is only called with the new EH, so the fact that it doesn't repro with |
|
It's actually affecting the |
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
May 15, 2024
There was an issue with unwinding native code functions in case of calls to no-return function placed at an end of a function code block. The return address was not in range of the function code, so RtlLookupFunctionEntry was not finding anything, we were thinking that it was a leaf function due to that and tried to unwind using LR only, which was wrong and resulted in staying on the same instruction. Thus the unwinding ended up in an infinite loop for those cases. The fix, that matches what RtlUnwind does, is to adjust the instruction pointer at call sites back. This is arm64 specific. Close dotnet#101921
janvorli
added a commit
to janvorli/runtime
that referenced
this issue
May 15, 2024
There was an issue with unwinding native code functions in case of calls to no-return function placed at an end of a function code block. The return address was not in range of the function code, so RtlLookupFunctionEntry was not finding anything, we were thinking that it was a leaf function due to that and tried to unwind using LR only, which was wrong and resulted in staying on the same instruction. Thus the unwinding ended up in an infinite loop for those cases. The fix, that matches what RtlUnwind does, is to adjust the instruction pointer at call sites back. This is arm64 specific. Close dotnet#101921
janvorli
added a commit
that referenced
this issue
May 16, 2024
* Fix Windows Arm64 unwinding There was an issue with unwinding native code functions in case of calls to no-return function placed at an end of a function code block. The return address was not in range of the function code, so RtlLookupFunctionEntry was not finding anything, we were thinking that it was a leaf function due to that and tried to unwind using LR only, which was wrong and resulted in staying on the same instruction. Thus the unwinding ended up in an infinite loop for those cases. The fix, that matches what RtlUnwind does, is to adjust the instruction pointer at call sites back. This is arm64 specific. Close #101921 * Modify the ifdef from CONTEXT_UNWOUND_TO_CALL to TARGET_ARM64
Ruihan-Yin
pushed a commit
to Ruihan-Yin/runtime
that referenced
this issue
May 30, 2024
* Fix Windows Arm64 unwinding There was an issue with unwinding native code functions in case of calls to no-return function placed at an end of a function code block. The return address was not in range of the function code, so RtlLookupFunctionEntry was not finding anything, we were thinking that it was a leaf function due to that and tried to unwind using LR only, which was wrong and resulted in staying on the same instruction. Thus the unwinding ended up in an infinite loop for those cases. The fix, that matches what RtlUnwind does, is to adjust the instruction pointer at call sites back. This is arm64 specific. Close dotnet#101921 * Modify the ifdef from CONTEXT_UNWOUND_TO_CALL to TARGET_ARM64
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We have observed that some tests started to time out on Windows ARM64 outerloop runs, first run on commit d92ac1f. I assume something committed in the preceeding 24h will be the cause.
Example failure https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-b0ba224c9aa14ac7aa/System.Net.WebHeaderCollection.Tests/1/console.ebb7fdfd.log?helixlogtype=result
The test itself just calling a ctor and checks for exception type, there is nothing that can be expected to hang.
runtime/src/libraries/System.Net.WebHeaderCollection/tests/WebHeaderCollectionTest.cs
Lines 51 to 59 in fa5dcda
There are more examples like this, the common thread is that the test involves throwing an exception. Compiling locally on ARM64 machine and attaching a debugger shows infinite loop in
runtime/src/coreclr/vm/frames.cpp
Lines 469 to 480 in 93f886f
With stacktrace
The text was updated successfully, but these errors were encountered: