There's maybe a memory leak somewhere

[zadjii-msft]

I don't know how exactly to trigger it. But it seems like when I go into the GitHub extension onto a query page, then back out, those list items never get released from memory. That's wack.

Repro steps

Easiest repro is to clone https://github.com/zadjii/CmdPalExtensions and build the SegoeIconsExtension there. That extension has a list of 1400 items in it, and instantiating it will burn like, 60MB of memory. It'll take a little while as it instantiates all the icons, but it'll work. Go into that page and out a few times, and the memory will just go up and never come back down.

Links:

• Frame/Page create a cycle that leaks microsoft/microsoft-ui-xaml#598
  • This sounds similar, but I think that one's problem is that freeing the Frame doesn't free either, because the Page keeps the Frame alive.
• Memory leak in NavigationView even though I cleared the child page element while unloading. microsoft/microsoft-ui-xaml#5978
• Navigation Memory Leak microsoft/microsoft-ui-xaml#934
• Memory leak when use x:Bind in winUI3 microsoft/microsoft-ui-xaml#7282

Things I've tried so far

my current tracking branch is dev/migrie/b/memory-leaks-3

• I tried making the IPageContext in ExtensionObjectViewModel a WeakReference. That didn't work.
• I tried the Cleanup.FrameworkElement from Navigation Memory Leak microsoft/microsoft-ui-xaml#934 (comment). That doesn't work.
• When we ListPage.NavigatingFrom, we do set the ViewModel to null. Someone else is holding it.
• I have a breakpoint in ListViewModel.Dispose. It's literally never hit.

[zadjii-msft]

I was also linked: microsoft/devhome#447 for reference. That uses static event handlers, but we'd need to have a cache of winrtObject -> ViewModel's somewhere for that to really work. Otherwise the static event handlers wouldn't be able to change the properties on the corresponding view model object

[zadjii-msft]

After #564, this is much less egregious, and I'm taking it out of blocking. There's still some memory that seems to grow after the initial stable state, but that might just be the allocation of brushes and icons that'll get cleaned up by XAML.