[release/5.0] Fix ComWrappers interaction with the IReferenceTracker interface #45622
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
Convert Managed Object Wrapper (MOW) GC Handle from HNDTYPE_STRONG
to HNDTYPE_REFCOUNTED.
Add new CreateObjectFlags value to indicate aggregation during
CreateObject scenario. This isn't reflected in the managed
.NET 5 API surface area.
In the ReferenceTracker scenario the ref count may never reach 0 so
the MOW destructor needs to handle that case. The previous expectation
for a null in the destructor was based on the STRONG handle logic.
During aggregation scenarios involving ReferenceTracker, ownership
of the inner is now the responsibility of the runtime.
AaronRobinsonMSFT
added
Servicing-consider
jeffschwMSFT
approved these changes
Dec 5, 2020
AaronRobinsonMSFT
changed the title
|
CoreCLR failures are fixed with #45525 |
AaronRobinsonMSFT
changed the title
This was referenced Dec 7, 2020
jkoritzinsky
approved these changes
Dec 7, 2020
|
// Auto-generated message 69e114c which was merged 12/7 removed the intermediate src/coreclr/src/ folder. This PR needs to be updated as it touches files in that directory which causes conflicts. To update your commits you can use this bash script: https://gist.github.com/ViktorHofer/6d24f62abdcddb518b4966ead5ef3783. Feel free to use the comment section of the gist to improve the script for others. |
|
@ViktorHofer This PR should be okay right? It is going into the |
|
Uff I didn't filter PRs out that target 5.0 :( Yes that one is fine. |
|
approved in tactics |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Issues: microsoft/CsWinRT#413, microsoft/microsoft-ui-xaml#3719
Description
A fundamental flaw was discovered during consumption of the
ComWrappersAPI (introduced .NET 5) in WinUI 3.0 scenarios. This was related to COM Aggregation and how C#/WinRT generated interop code.The work here corrects this issue and provides additional testing.
Customer Impact
Scenarios involving WinRT support provided by C#/WinRT with aggregation of WinRT types will leak memory with no recourse. This impacts consumption of the WinUI stack.
Regression
This API is new in .NET 5.0. However the API is used to address the removal of WinRT built-in support - #37672.
Testing
Additional E2E testing has been added in this PR. The scenario was also manually validated on a local build against the official XAML/Jupiter runtime using hand crafted interop code. A private build of coreclr was then shared with the C#/WinRT team for validation.
Risk
Minimal risk. The code paths in question are not used outside of the
ComWrappersAPI scenario - only known consumer is C#/WinRT and WinUI. The risk for these two consumers are as follows:Risk (1) means leaks may still exist but they are no worse off than the current code. There has been verified improvement, but it is possible additional leaks exist. Risk (2) is slightly more concerning but is mitigable if this PR results in early collection or use after free scenarios. The C#/WinRT code generation tool can introduce a quirk to explicitly leak the object instead of attempting to participate in collection.
Neither of these are expected but they represent reduced risk from the CoreCLR perspective.
/cc @Scottj1s @davidwrighton @jeffschwMSFT @MikeHillberg @elinor-fung @jkoritzinsky