Fix assert in Thread::VirtualUnwindCallFrame on ARM64 #102350
Conversation
My recent change to fix windows arm64 unwinding for native code has started to trigger an assert in jitstress tests. The problem is that the codeinfo that is passed to the Thread::VirtualUnwindCallFrame in case of managed frames was created from an unadjusted PC, while the check that we use to verify the codeinfo validity in debug builds gets the function entry from the OS using the adjusted address. The fix is to perform the adjustment only when codeinfo is not passed in.
|
Tagging subscribers to this area: @mangod9 |
|
@jkotas I was originally considering instantiating the CodeInfo from PC adjusted in the same manner, but there are too many places where that happens. |
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress |
|
Azure Pipelines successfully started running 2 pipeline(s). |
| @@ -554,7 +554,11 @@ PCODE Thread::VirtualUnwindCallFrame(T_CONTEXT* pContext, | |||
| PT_RUNTIME_FUNCTION pFunctionEntry; | |||
|
|
|||
| #if !defined(TARGET_UNIX) && defined(TARGET_ARM64) | |||
| if ((pContext->ContextFlags & CONTEXT_UNWOUND_TO_CALL) != 0) | |||
| // We don't adjust the control PC when we have a code info, as the code info is always created from an unadjusted one | |||
There was a problem hiding this comment.
Is the unadjusted code info going to work well for the unwind? In other words, can we hit the bug that you have fixed when the code info is passed in?
There was a problem hiding this comment.
The code info is passed in only for managed frames. If it was not the case, the code info would not be valid and the assert I am fixing would be firing.
Return address in managed code is never out of the bounds of the method containing the call, otherwise unwinding managed code would be crashing / hanging on arm64 Windows both with and without the new EH.
|
Any idea what causes jitstress in particular to hit this issue? |
|
@jakobbotsch the way how the managed method gets covered by multiple RUNTIME_FUNCTIONS seems to be jitstress specific. |
|
Ah, this is likely our unwind stress mode then. In that mode we split the function into multiple fragments even when the function doesn't exceed the max fragment size. |
My recent change to fix windows arm64 unwinding for native code has started to trigger an assert in jitstress tests. The problem is that the codeinfo that is passed to the Thread::VirtualUnwindCallFrame in case of managed frames was created from an unadjusted PC, while the check that we use to verify the codeinfo validity in debug builds gets the function entry from the OS using the adjusted address. The fix is to perform the adjustment only when codeinfo is not passed in.
My recent change to fix windows arm64 unwinding for native code has started to trigger an assert in jitstress tests. The problem is that the codeinfo that is passed to the Thread::VirtualUnwindCallFrame in case of managed frames was created from an unadjusted PC, while the check that we use to verify the codeinfo validity in debug builds gets the function entry from the OS using the adjusted address.
The fix is to perform the adjustment only when codeinfo is not passed in.
Close #102337