[release/7.0] Prevent unwinding through stack bottom #81804
Merged
Conversation
This file contains 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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
janvorli
added
area-ExceptionHandling-coreclr
Servicing-consider
jkotas
approved these changes
Feb 8, 2023
jeffschwMSFT
approved these changes
Feb 8, 2023
janvorli
added
the
NO-MERGE
|
I've found a bug in the change, looking into it. |
janvorli
removed
the
NO-MERGE
|
Bug fixed in main, merged in, cherry picked the commit to this PR. |
When processing unhandled exception on the most recent Alpine 3.17, the libunwind doesn't stop at the bottom frame of the main thread (the caller of `main`) and tries to unwind further. The reason is that the method is missing dwarf unwind information, so the libunwind falls back to using RBP chain, but the RBP points to a garbage and so it ends up crashing with SIGSEGV. While the missing DWARF unwind info seems to be a bug in the Alpine 3.17 (older ones work fine), we can prevent issues like this by stopping at the hosting API boundary and not trying to unwind past that. This is what this PR does.
The irecent fix to prevent unwinding through stack bottom was incorrect for secondary threads, as it just compared the SP being above the frame of the hosting API. However, other threads can have their stacks anywhere in the memory, thus this sometimes broke exception handling on secondary threads. I have also found that there was one more case where the unwind through the hosting API need to be checked - the Thread::VirtualUnwindToFirstManagedCallFrame. I have decided to use the return address of the hosting API for the checks instead of the frame address. That makes the check work properly.
carlossanlop
force-pushed
the
backport/pr-81770-to-release/7.0
branch
from
f7be1b9 to
f60800e
Compare
carlossanlop
added
Servicing-approved
|
Approved by Tactics via email for 7.0.4. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 #81770 to release/7.0
When processing unhandled exception on the most recent Alpine 3.17, the libunwind doesn't stop at the bottom
frame of the main thread (the caller of main) and tries to unwind further. The reason is that the method is missing dwarf unwind information, so the libunwind falls back to using RBP chain, but the RBP points to a garbage and so it ends up crashing with SIGSEGV.
While the missing DWARF unwind info seems to be a bug in the Alpine 3.17 (older ones work fine), we can prevent issues like this by stopping at the hosting API boundary and not trying to unwind past that
/cc @janvorli
Customer Impact
Without this fix, unhandled exception on the latest Alpine 3.17 results in an access violation crash without any message generated. It impacts our public Alpine docker containers for .NET 7 and 6.
Testing
Targeted testing of the fix, coreclr tests, libraries tests.
Risk
Low, the change only stops unwinding stack when it reaches the hosting API frame. No exception can be handled past that.