Multi-window memory leak #10029

vfabulokwe · 2022-09-09T23:57:48Z

Description

Closing a window results in a memory leak. The windows are never GC’d and often all their content is still visible within memory. Comparing this behavior with WinUI3 I have found that it works correctly in WinUI3, windows are created and recycled, counts go up, and back down. On MAUI the same process results in a steady increase in Window counts.

Steps to Reproduce

Create new MAUI app
Add a button in the MainPage.xaml and implement the Clicked event handler in the code behind.

// button - to open a new window
private void BlankWinLeakBtn_Clicked(object sender, EventArgs e)
{
var page = new ContentPage()
{
Content = new Label()
{
Text = ""
}
};
var win = new Window()
{
Page = page
};

    App.Current.OpenWindow(win);
}

Click on the button
Take snapshot
Close window
Click button again
Take snapshot
Close window
Repeat steps 1-6 multiple times
Compare snapshots

Expected Result:
Ref count should go down when a window is closed.

Actual Result:
Ref count keeps going up, window is never GC'd.

Link to public reproduction project repository

NA

Version with bug

Unknown/Other (please specify)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

All

Did you find any workaround?

No response

Relevant log output

No response

ghost · 2022-09-13T18:27:06Z

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

jsuarezruiz · 2022-09-28T09:22:56Z

Related with microsoft/microsoft-ui-xaml#7617

mouralabank · 2022-12-06T11:41:59Z

The same problem here, any workaround?

danielancines · 2022-12-06T16:27:58Z

I've been making some tests here, and the problem appears to be in a Window object that still forever allocated, in my tests, even I closed New Window and check if it removed from App.Current.Windows collection, the object never will be collect by GC and I cannot find who is locking up on the object tree. Unfortunately I didn't find any workaround for this issue, do you guys have any idea?

Context: dotnet#10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. This is a perfect example of where using `ConditionalWeakTable` solves the issue: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. Note this doesn't fully solve dotnet#10029, as I still see something else holding onto `Window` in my example. This is WIP, as I'm interested in what my `WindowsDoNotLeak` test will do on all platforms.

Fixes: dotnet#10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. This is a perfect example of where using `ConditionalWeakTable` solves the issue: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. After these changes, I still found `Window` objects hanging around that appeared to be held onto by many other objects. Then I reviewed: void IWindow.Destroying() { SendWindowDisppearing(); Destroying?.Invoke(this, EventArgs.Empty); OnDestroying(); Application?.RemoveWindow(this); // This wasn't here! Handler?.DisconnectHandler(); } It appears that upon `Window`'s closing, we didn't have any code that "disconnected" the MAUI handler. After this change, I could see `Window` objects properly go away. I added a unit test as well.

Fixes: dotnet#10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. Note that we *can't* use `ConditionalWeakTable` here: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 After initially trying this, I added a test showing not to use it. The problem is if the `string` is GC'd the `Window` will be lost. We can use `Dictionary<string, WeakReference<Window>>` instead. The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. After these changes, I still found `Window` objects hanging around that appeared to be held onto by many other objects. Then I reviewed: void IWindow.Destroying() { SendWindowDisppearing(); Destroying?.Invoke(this, EventArgs.Empty); OnDestroying(); Application?.RemoveWindow(this); // This wasn't here! Handler?.DisconnectHandler(); } It appears that upon `Window`'s closing, we didn't have any code that "disconnected" the MAUI handler. After this change, I could see `Window` objects properly go away. I added a unit test as well.

Fixes: #10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. Note that we *can't* use `ConditionalWeakTable` here: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 After initially trying this, I added a test showing not to use it. The problem is if the `string` is GC'd the `Window` will be lost. We can use `Dictionary<string, WeakReference<Window>>` instead. The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. After these changes, I still found `Window` objects hanging around that appeared to be held onto by many other objects. Then I reviewed: ```csharp void IWindow.Destroying() { SendWindowDisppearing(); Destroying?.Invoke(this, EventArgs.Empty); OnDestroying(); Application?.RemoveWindow(this); // This wasn't here! Handler?.DisconnectHandler(); } ``` It appears that upon `Window`'s closing, we didn't have any code that "disconnected" the MAUI handler. After this change, I could see `Window` objects properly go away. I added a unit test as well.

Fixes: #10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. Note that we *can't* use `ConditionalWeakTable` here: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 After initially trying this, I added a test showing not to use it. The problem is if the `string` is GC'd the `Window` will be lost. We can use `Dictionary<string, WeakReference<Window>>` instead. The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. After these changes, I still found `Window` objects hanging around that appeared to be held onto by many other objects. Then I reviewed: ```csharp void IWindow.Destroying() { SendWindowDisppearing(); Destroying?.Invoke(this, EventArgs.Empty); OnDestroying(); Application?.RemoveWindow(this); // This wasn't here! Handler?.DisconnectHandler(); } ``` It appears that upon `Window`'s closing, we didn't have any code that "disconnected" the MAUI handler. After this change, I could see `Window` objects properly go away. I added a unit test as well. # Conflicts: # src/Controls/tests/Core.UnitTests/WindowsTests.cs

Fixes: #10029 I could reproduce a memory leak by doing: App.Current.OpenWindow(new Window { Page = new ContentPage() }); I found that `App.Current._requestedWindows` just held onto every `Window` object forever. Note that we *can't* use `ConditionalWeakTable` here: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.conditionalweaktable-2 After initially trying this, I added a test showing not to use it. The problem is if the `string` is GC'd the `Window` will be lost. We can use `Dictionary<string, WeakReference<Window>>` instead. The only other change I made was to use `Guid.ToString("n")` as it removes `{`, `}`, and `-` characters from the string. After these changes, I still found `Window` objects hanging around that appeared to be held onto by many other objects. Then I reviewed: ```csharp void IWindow.Destroying() { SendWindowDisppearing(); Destroying?.Invoke(this, EventArgs.Empty); OnDestroying(); Application?.RemoveWindow(this); // This wasn't here! Handler?.DisconnectHandler(); } ``` It appears that upon `Window`'s closing, we didn't have any code that "disconnected" the MAUI handler. After this change, I could see `Window` objects properly go away. I added a unit test as well. # Conflicts: # src/Controls/tests/Core.UnitTests/WindowsTests.cs Co-authored-by: Shane Neuville <shneuvil@microsoft.com>

vfabulokwe added the t/bug Something isn't working label Sep 9, 2022

jsuarezruiz added the legacy-area-perf Startup / Runtime performance label Sep 12, 2022

PureWeen added the platform/windows 🪟 label Sep 13, 2022

PureWeen added this to the Backlog milestone Sep 13, 2022

samhouts added partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with p/1 Work that is important, and has been scheduled for release in this or an upcoming sprint labels Sep 20, 2022

jsuarezruiz mentioned this issue Oct 25, 2022

[Windows] Disconnect events and dispose the Content before close the Window #10886

Closed

samhouts modified the milestones: Backlog, .NET 8 Planning Jan 26, 2023

jonathanpeppers self-assigned this Feb 16, 2023

jonathanpeppers mentioned this issue Feb 16, 2023

[controls] fix memory leak in Window #13400

Merged

PureWeen closed this as completed in #13400 Mar 1, 2023

ghost locked as resolved and limited conversation to collaborators Apr 1, 2023

samhouts added the fixed-in-8.0.0-preview.3.8149 Look for this fix in 8.0.0-preview.3.8149! label Apr 12, 2023

Eilon added the t/perf The issue affects performance (runtime speed, memory usage, startup time, etc.) label May 10, 2024

samhouts added the memory-leak 💦 Memory usage grows / objects live forever label Oct 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multi-window memory leak #10029

Multi-window memory leak #10029

vfabulokwe commented Sep 9, 2022 •

edited by Eilon

Loading

ghost commented Sep 13, 2022

jsuarezruiz commented Sep 28, 2022

mouralabank commented Dec 6, 2022

danielancines commented Dec 6, 2022

Multi-window memory leak #10029

Multi-window memory leak #10029

Comments

vfabulokwe commented Sep 9, 2022 • edited by Eilon Loading

Description

Steps to Reproduce

Link to public reproduction project repository

Version with bug

Last version that worked well

Affected platforms

Affected platform versions

Did you find any workaround?

Relevant log output

ghost commented Sep 13, 2022

jsuarezruiz commented Sep 28, 2022

mouralabank commented Dec 6, 2022

danielancines commented Dec 6, 2022

vfabulokwe commented Sep 9, 2022 •

edited by Eilon

Loading