-
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
[release/6.0] Fix Crossgen2 bug #61104 and add regression test #64027
Conversation
The issue tracks the runtime regression failure where Crossgen2-compiled app is unable to locate a type with non-ASCII characters in its name. The failure was caused by the fact that Crossgen2 was incorrectly zero-extended the individual characters when calculating the hash whereas runtime is sign-extending them. Thanks Tomas
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 should take for consideration in 6.0.x
Eek, it is not the right time to merge (quite yet). We need to wait for a checkin window and request approval. @mmitche to help stop this from flowing. |
Hmm, sorry about that, I was under the impression that the actual move to the servicing release will happen as a subsequent step. Thanks Jeff for letting me know, I'll remember it the next time. |
Are there builds with this fix available yet? |
@Tragetaschen not yet, these builds will start to show up on https://github.com/dotnet/installer in the coming week. |
Backport of #63956 to release/6.0
/cc @mangod9 @trylek
Customer Impact
Fixes issue reported by multiple customers where Crossgen2-compiled apps fail runtime reflection lookup for types with non-ASCII characters in their names, in particular:
#61104
#63193
#63481
Testing
As part of fixing the bug I locally reproed the failure in 61104 and I used comparative debugging to observe the native runtime vs. Crossgen2 code path that revealed the subtle difference in type hash code calculation. After fixing the discrepancy I locally observed the hash codes getting in sync between the CoreCLR runtime and Crossgen2 even for types with names containing non-ASCII characters. As part of the fix I created a regression test based on the bug report 61104 and I ran a successful [modulo minor infra hiccups] outerloop run.
Risk
Extremely low - the fix only affects a corner case of type names containing non-ASCII characters; the two algorithms, their previous divergence and its fix in the PR proposed for porting are well understood and quite trivial to reason about; the fix is well localized and literally involves about 20 characters in a single method.