Skip to content
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

Merged
merged 2 commits into from
Jan 20, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Jan 20, 2022

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.

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
Copy link
Member

@jeffschwMSFT jeffschwMSFT left a 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

@jeffschwMSFT jeffschwMSFT added the Servicing-consider Issue for next servicing release review label Jan 20, 2022
@trylek trylek merged commit bbfc15c into release/6.0 Jan 20, 2022
@trylek trylek deleted the backport/pr-63956-to-release/6.0 branch January 20, 2022 17:21
@jeffschwMSFT
Copy link
Member

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.

@trylek
Copy link
Member

trylek commented Jan 20, 2022

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.

@leecow leecow added this to the 6.0.3 milestone Jan 20, 2022
@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Jan 20, 2022
@Tragetaschen
Copy link
Contributor

Are there builds with this fix available yet?

@jeffschwMSFT
Copy link
Member

@Tragetaschen not yet, these builds will start to show up on https://github.com/dotnet/installer in the coming week.

@ghost ghost locked as resolved and limited conversation to collaborators Mar 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-crossgen2-coreclr Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants