-
Notifications
You must be signed in to change notification settings - Fork 5k
Fix for stress failure when adjusting effective IP while stackwalking may put it on a wrong instruction. #100376
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -712,7 +712,9 @@ void CodeGen::genCodeForBBlist() | |
|
||
if ((call != nullptr) && (call->gtOper == GT_CALL)) | ||
{ | ||
if ((call->AsCall()->gtCallMoreFlags & GTF_CALL_M_DOES_NOT_RETURN) != 0) | ||
if ((call->AsCall()->gtCallMoreFlags & GTF_CALL_M_DOES_NOT_RETURN) != 0 || | ||
((call->AsCall()->gtCallType == CT_HELPER) && | ||
Compiler::s_helperCallProperties.AlwaysThrow(call->AsCall()->GetHelperNum()))) | ||
{ | ||
instGen(INS_BREAKPOINT); // This should never get executed | ||
} | ||
|
@@ -756,6 +758,20 @@ void CodeGen::genCodeForBBlist() | |
|
||
case BBJ_ALWAYS: | ||
{ | ||
GenTree* call = block->lastNode(); | ||
if ((call != nullptr) && (call->gtOper == GT_CALL)) | ||
{ | ||
if ((call->AsCall()->gtCallMoreFlags & GTF_CALL_M_DOES_NOT_RETURN) != 0 || | ||
((call->AsCall()->gtCallType == CT_HELPER) && | ||
Compiler::s_helperCallProperties.AlwaysThrow(call->AsCall()->GetHelperNum()))) | ||
{ | ||
// NOTE: We should probably never see a BBJ_ALWAYS block ending with a throw in a first place. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I take it you did see such cases? Can you open an issues for us to follow-up and switch them over to BBJ_THROWs? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note this might largely clean itself up by adding the logic to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, I wanted this to be an assert, so it would not happen by accident in the future. To my surprise, the assert was triggered by existing code. |
||
// If that is fixed, this condition can be just an assert. | ||
// For the reasons why we insert a BP, see the similar code in "case BBJ_THROW:" above. | ||
instGen(INS_BREAKPOINT); // This should never get executed | ||
} | ||
} | ||
|
||
// If this block jumps to the next one, we might be able to skip emitting the jump | ||
if (block->CanRemoveJumpToNext(compiler)) | ||
{ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we extend
GenTreeCall::IsNoReturn()
to cover the helper case too? Either by setting the no return flag when the helper is set, or by putting this check there?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tried, naively, to put
in
gtNewHelperCallNode
, but that resulted in
I could not easily tell if the assert is just an observation, that could be relaxed or indeed guarding some assumptions made in the code, so I did not continue on that path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commenting out that assert leads to others:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'd prefer entering an issue on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, looks like there are some assumptions in the throw helper merging to sort out.