[release/7.0] Fix macOS floating point corruption#75467
Merged
carlossanlop merged 1 commit intorelease/7.0from Sep 12, 2022
Merged
[release/7.0] Fix macOS floating point corruption#75467carlossanlop merged 1 commit intorelease/7.0from
carlossanlop merged 1 commit intorelease/7.0from
Conversation
There is a race condition between activation signal handling and returning from a hardware exception handler on macOS. It shows up intermittently in the Regression/coreclr/GitHub_16833 test in the CI and I am able to repro it on my local mac once in several thousands of iterations of the test when running with GC stress C. It turned out the issue is caused by the order in which we set parts of the context in the thread when returning from the hardware exception handler. MacOS can only set the floating point and control / integer portions separately. We were setting the control / integer portion first and the floating point portion after that. In the race condition, the signal handling code in the macOS extracts the context that contains the new control registers, but the old floating point ones (which is the state of those in the PAL_DispatchException). The signal handler for the activation injection then gets executed and when it returns later to our managed code, the floating point registers get restored to the wrong values. The fix is to change the context setting to first set the floating point registers and then the control / integer portion of the context. Close #66568
ghost
added
the
mangod9
approved these changes
Sep 12, 2022
jeffschwMSFT
approved these changes
Sep 12, 2022
Member
jeffschwMSFT
left a comment
jeffschwMSFT
left a comment
There was a problem hiding this comment.
approved. once we get a green ci we can merge
Contributor
|
CI is green. Approved and signed off. Ready to merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #75440 to release/7.0
/cc @janvorli
Customer Impact
Very rare and extremely difficult to diagnose corruption of floating point values.
Testing
CI tests, local coreclr tests and especially running the test Regression/coreclr/GitHub_16833 where that problem was occurring randomly in our CI and that can reproduce the issue once in several thousands iterations.
Risk
Very low, it only changes the order of setting floating point / general purpose + control context parts on a thread that is returning from hardware exception handling.