[release/10.0-rc1] JIT: fix issue with EH clause class types for fault/filters from C++/CLI #118905
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #118870 to release/10.0-rc1
/cc @AndyAyersMS
Customer Impact
Reported by @thoenissen in #118837.
Regression
In .NET 10 the JIT can now inline some methods with EH. When a C++/CLI method with a fault or filter clause is inlined into a dynamic method, it exposes a pre-existing issue where the runtime will try and interpret the
classToken
field of the finally/filter EH clause as a class handle, despite the fact that this field has no meaning for those kinds of clauses. C++/CLI leaves garbage values these fields and the JIT simply passes that field along to the runtime, leading to unexpectedInvalidProgramExceptions
from the runtime.Testing
Tested the fix using the example from the customer.
Risk
Low. The JIT now zeros the
classToken
field for finally/fault clauses, and the runtime no longer looks at the field values.