-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[6.0] Fix the tiering delay to account for changing IL/native code versions during the delay #78670
Conversation
…rsions during the delay - Port of dotnet#78668 - Added a check to see if the currently active native code version has a code entry point Fixes dotnet#77973
@kouvel for the January servicing release, we only have a window of one day to merge backports (from Nov. 29th to Nov. 30th). For that reason, I'm asking all backport submitters to make sure the PR is ready for me to just hit the merge button on that day. If this is ready, please ask @jeffschwMSFT if he approves the backport. If approved, then: |
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.
approved. we will take for consideration in 6.0.x
Branding has been done. Milestone is 6.0.13. Approved by Tactics. Signed-off by area owners. CI is green. No OOB package authoring changes needed. |
Fixes #77973
Customer Impact
Apps that use profiler APIs to modify a method's IL may occasionally crash. If a new IL code version is added to a method while it's queued for call counting during the tiering delay, after the delay expires a call counting stub may be created that when called, would cause the app to crash. A workaround is to disable tiered compilation.
Regression?
No
Testing
Reproed the issue by inducing the timing with code changes and verified the fix. Scanned over the few other paths where call counting stubs would be created and verified that all of them guarantee a non-null code entry point for the method.
Risk
Low