Fix macOS floating point corruption#75440
Merged
janvorli merged 1 commit intodotnet:mainfrom Sep 12, 2022
Merged
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 dotnet#66568
Member
Author
|
cc: @mangod9 |
Member
Author
|
cc: @AntonLapounov |
Member
What prevents the opposite case, i.e. using the old control registers with the new floating point ones? Thanks for catching this! |
jkotas
reviewed
Sep 12, 2022
| } | ||
| } | ||
|
|
||
| if (lpContext->ContextFlags & (CONTEXT_CONTROL|CONTEXT_INTEGER) & CONTEXT_AREA_MASK) |
Member
There was a problem hiding this comment.
It may be useful to add a note that the integer/control registers have to be set last.
Member
Author
|
/backport to release/7.0 |
Contributor
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3039605422 |
ghost
locked as resolved and limited conversation to collaborators
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.
3 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.
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.I have figured this out by adding some instrumentation to the PAL / runtime, logging state of the
PCandD0registers to the stresslog in activation handler / hardware exception handler. I could see that the hardware exception handler was getting correctD0at aPCand right away the activation handler was getting a corruptedD0at the samePCand theD0matched what the formatted string contained in the failing test instead of the correct value (0xcccccccccccccccc or rarely 0).The fix is to change the context setting to first set the floating point registers and then the control / integer portion of the context.
With the fix, the test was running over the whole weekend without any crashes.
Close #66568