-
Notifications
You must be signed in to change notification settings - Fork 5.1k
[release/6.0] Fix exception propagation over HW exception frame on macOS arm64 #63524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There is a bug in setting up the fake stack frame for the PAL_DispatchExceptionWrapper. The FP and SP were not saved to the stack frame and the FP of the context was not set to match the fake prologue. That caused failure to unwind over the PAL_DispatchExceptionWrapper, reaching an unrelated native function. This change fixes it.
Unifies the hardware exception frame unwinding with Linux, it is necessary on arm64 to get correct and distinct LR and PC in the frame of the hardware exception.
System.Composition.Hosting.Core.Tests.ExportDescriptorPromiseTests.GetDescriptor_GetWhenNull_ThrowsNullReferenceException timed out. Coincidental, most likely as altough it's macOS it's x64. |
@danmoseley thank you for pointing it out. I'll test it locally. |
There is really something wrong with the EH in this test. The EH gets into an infinite loop, so there is something subtle that I must have missed. |
I am closing this porting PR until the issue is found and fixed. |
I see that there is no such Libraries Test Run build for OSX arm64, probably that's why only x64 build failed. |
/azp list |
/azp help |
It should be possible to request it next time with |
The failure is intermittent, that's why I haven't hit it in the main branch and local testing. But I am able to repro it locally in a reasonable number of attempts. |
Backport of #63482 to release/6.0
/cc @janvorli
There is a bug in hardware exception handling on macOS arm64 in setting up
the fake stack frame for the PAL_DispatchExceptionWrapper. Unwinding
while propagating an exception through the frame that caused the hardware
exception restores incorrect value of the LR register.
Customer Impact
Attempt to throw a new exception or rethrow from a catch handler of a NullReferenceException that stemmed from a virtual call on a
null
reference results in a SIGSEGV crash of the process on macOS arm64.Testing
coreclr and libraries tests, targeted regression test.
Risk
Low. With the change, the unwind gets an exact copy of the frame of the hardware exception that was reported by the OS. So it is correct by definition.