Clear inlinee callinfo from the catch of OP_TryFinally as well #4449
Conversation
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
Contributor
Author
|
Reopened against release/1.8. Addressed review comment |
Contributor
|
How did you address @LouisLaf 's concerns from the previous PR? |
Contributor
Author
|
#4051 (comment) was regarding the use of the isInlineeCleared Boolean that I used to avoid do the stack walk and clear when there is a try catch/try finally nesting. The suggestion was to use a stack to restore previous state correctly. My 2nd commit in the PR addresses this. I had added isInlineeCleared bit to mark when we have cleared inlinee frames's callinfo count on an exception within a try finally enclosed in some try catch. |
89db484 to
a42c710
Compare
3890234 to
18ea70c
Compare
Contributor
Author
|
@dotnet-bot test OSX static_osx_osx_debug |
added 2 commits
January 16, 2018 13:21
When we hit an exception and we have a try finally within a try catch. We will execute finally code by calling BailOnException. Since we inline into functions with try now, we will end up in inconsistent inlinee callinfo when we call the bailout code from finally. So add the walker and clear inlinee callinfo. Remove isInlineeCleared bit I had added isInlineeCleared bit to mark when we have cleared inlinee frames's callinfo count on an exception within a try finally enclosed in some try catch. I later checked this bit in the enclosing OP_TryCatch to make sure we don't walk the stack to clear info again. This is not needed, because if there was an expection within try finally, then we will bailout and never exercise the code in OP_TryCatch
When a stackoverflow happens within a try finally enclosed inside try catch, we have to do a stackwalk till we find the try catch frame, this means walking all the frames that caused the stackoverflow. This test takes longer than the default timeout value on xplat. Moving it to slow test.
18ea70c to
a29fd05
Compare
chakrabot
pushed a commit
that referenced
this pull request
Jan 16, 2018
…TryFinally as well Merge pull request #4449 from meg-gupta:swandclearinlineinfo When we hit an exception and we have a try finally within a try catch. We will execute finally code by calling BailOnException. Since we inline into functions with try now, we will end up in inconsistent inlinee callinfo when we call the bailout code from finally. So add the walker and clear inlinee callinfo. Also move tryCatchAddr ctor inside a scope, so that it executes before user catch code. Fixes OS#14336922
chakrabot
pushed a commit
that referenced
this pull request
Jan 17, 2018
…tch of OP_TryFinally as well Merge pull request #4449 from meg-gupta:swandclearinlineinfo When we hit an exception and we have a try finally within a try catch. We will execute finally code by calling BailOnException. Since we inline into functions with try now, we will end up in inconsistent inlinee callinfo when we call the bailout code from finally. So add the walker and clear inlinee callinfo. Also move tryCatchAddr ctor inside a scope, so that it executes before user catch code. Fixes OS#14336922
chakrabot
pushed a commit
that referenced
this pull request
Jan 17, 2018
…o from the catch of OP_TryFinally as well Merge pull request #4449 from meg-gupta:swandclearinlineinfo When we hit an exception and we have a try finally within a try catch. We will execute finally code by calling BailOnException. Since we inline into functions with try now, we will end up in inconsistent inlinee callinfo when we call the bailout code from finally. So add the walker and clear inlinee callinfo. Also move tryCatchAddr ctor inside a scope, so that it executes before user catch code. Fixes OS#14336922
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When we hit an exception and we have a try finally within a try catch. We will execute finally code by calling BailOnException.
Since we inline into functions with try now, we will end up in inconsistent inlinee callinfo when we call the bailout code from finally.
So add the walker and clear inlinee callinfo.
Also move tryCatchAddr ctor inside a scope, so that it executes before user catch code.
Fixes OS#14336922