[release/9.0-staging] [mono][aot] Fix compilation crashes when type load exception is generated in code #110271
+4
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Method compilation was continuing and we ended up failing with invalid IL.
…ption throw In the final stages of method compilation, when trying to compute clause ranges, we were asserting because the clause bblocks haven't been reached for compilation.
|
Tagging subscribers to this area: @steveisok, @vitek-karas |
This was referenced Nov 29, 2024
BrzVlad
added
Servicing-consider
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #110078 to release/9.0-staging
Customer Impact
AOT of some assemblies can lead to compilation crashes, on iOS for example. This would force users to use interpreter instead.
Regression
Yes.
Testing
Tested with sample application provided by customer.
Risk
Low. In rare cases, when typeload exception was detected during compile time, we were emitting code to throw this exception at runtime (this was behavior introduced in net9). This functionality had bugs leading to crashes instead during compilation. This PR has impact only on those scenarios that were already crashing.