Skip to content

[release/6.0] Fix Crossgen2 bug #61104 and add regression test - #64027

Merged
trylek merged 2 commits into
release/6.0from
backport/pr-63956-to-release/6.0
Jan 20, 2022
Merged

[release/6.0] Fix Crossgen2 bug #61104 and add regression test#64027
trylek merged 2 commits into
release/6.0from
backport/pr-63956-to-release/6.0

Conversation

@github-actions

@github-actionsgithub-actionsBot commented Jan 20, 2022

Copy link
Copy Markdown
Contributor

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
@ghostghost added the area-ReadyToRun label Jan 20, 2022

@jeffschwMSFTjeffschwMSFT left a comment

Copy link
Copy Markdown
Member

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

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

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

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.

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

Copy link
Copy Markdown
Contributor

Are there builds with this fix available yet?

@jeffschwMSFT

Copy link
Copy Markdown
Member

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

@ghostghost locked as resolved and limited conversation to collaborators Mar 14, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-ReadyToRunServicing-approvedApproved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@jeffschwMSFT@trylek@Tragetaschen@mangod9@leecow