WinUI 3 Page objects are being leaked on navigate in a C#/WinRT app

[llongley]

I've put together two sample apps to demonstrate the same scenario, one in C++/WinRT, the other in C#/WinRT:

C++/WinRT: DesktopWinUICppLeakTest.zip

C#/WinRT: DesktopWinUICSharpLeakTest.zip

In both cases, the app contains a ListView containing 1,000 items, plus a button that navigates to and from a second page also containing a ListView with 1,000 items. In the C++/WinRT case, the memory footprint of the app stays the same after successive navigations, whereas in the C#/WinRT case, the memory footprint steadily grows. A heap dump analysis indicates that the root Page object in native code is what's leaking, so it's likely the case that something in the C#/WinRT projection is holding onto the native object past when it should be.

[AdamBraden]

angelazhangmsft - relnote for RC2.

[BenJKuhn]

Here's an update on the investigation. We've tightened up reference cleanup, but there is still one lingering cycle, and it's a challenging one. This object will always leak upon creation:

class TestPage : Page { }

In simplest terms, to create the XAML page, CSWinRT creates a CCW for TestPage, so that it can override methods on Page. So far so good. However, Page is serving double-duty in this instance. It's both the access to the base implementation for the derived object, and the lifetime management for clients in C# to access the combined object. This net effect is that there's a strong reference cycle between the XAML page & CCW of TestPage, and the CCW isn't aggregating it's lifetime with the XAML page (nor can it, it needs to be created first to create the XAML page.

Correcting this leak is going to require some careful thought about how the aggregate object is assembled.

[Scottj1s]

See repro unit test:
https://github.com/microsoft/CsWinRT/tree/scottj1s/TestComposableGC

[Scottj1s]

CLR bug fix:
https://github.com/AaronRobinsonMSFT/runtime/tree/tracker_bug