Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Windows] Window Memory Leak #22973

Closed
danielancines opened this issue Jun 11, 2024 · 18 comments · Fixed by #23327
Closed

[Windows] Window Memory Leak #22973

danielancines opened this issue Jun 11, 2024 · 18 comments · Fixed by #23327
Labels
area-controls-window Window fixed-in-8.0.70 fixed-in-9.0.0-preview.7.24407.4 memory-leak 💦 Memory usage grows / objects live forever (sub: perf) platform/windows 🪟 s/needs-attention Issue has more information and needs another look t/bug Something isn't working

Comments

@danielancines
Copy link

Description

I'm working for a big company and we having memory leaks issues, when user opens a new window, the memory on Task Manager never is released and still increasing. To test purposes, I created a fresh new Maui .net 8 app and got some weird behaviors.

After open 5 windows and closing them, opening more 9 windows and closing them, it appears that old 5 windows come back to life and still on the heap. Other issue is, the memory on task manager never is released and still increasing with more windows creation. Sometimes the old windows come back to life to and the number os Controls.Window are increased on the next snapshot.

image

Steps to Reproduce

  1. Create new .dotnet 8 Maui app.
  2. The steps to reproduce are described above.

Link to public reproduction project repository

https://github.com/danielancines/memory-leak-dotnet8-maui

Version with bug

8.0.3 GA

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

No response

@danielancines danielancines added the t/bug Something isn't working label Jun 11, 2024
@danielancines danielancines changed the title Windows Memory Leak Window Memory Leak Jun 11, 2024
Copy link
Contributor

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

@jsuarezruiz jsuarezruiz added memory-leak 💦 Memory usage grows / objects live forever (sub: perf) platform/windows 🪟 labels Jun 11, 2024
@rodirigos
Copy link

Still having similar problems in dotnet8. Can you please provide a fix for this problem? I'm cleaning all the events and even a empty window can cause this after a while.

@drasticactions drasticactions changed the title Window Memory Leak [Windows] Window Memory Leak Jun 11, 2024
@RoiChen001 RoiChen001 added s/verified Verified / Reproducible Issue ready for Engineering Triage s/triaged Issue has been reviewed labels Jun 12, 2024
@RoiChen001
Copy link

Can repro this issue at Windows platform on the latest 17.11.0 Preview 2.0(8.0.0-rc.2.9530&8.0.40).

@danielancines
Copy link
Author

danielancines commented Jun 19, 2024

Hi guys, I'm running a lot of tests on Maui repo and the reasons for Window memory leak appears in a lot of places
image
image

Myview is a custom ContentView that stay on memory after window close. I found an event that never unassigned on VisualDiagnosticsOverlay
image
image

Still looking for a workaround, because this problem still crashing my app because memory still increasing after hours of working.

@danielancines
Copy link
Author

danielancines commented Jun 19, 2024

I've been running some tests with WinUI3 and apparently has the same problem, the memory still increasing and never released.

@lfmouradasilva
Copy link

I have the same problem in my project that has already been launched in production. Does anyone have a workaround?

@fpedrolucas95
Copy link

I have the same problem in my project, and this issue is crucial for us.

@ImLusca
Copy link

ImLusca commented Jun 20, 2024

Got the same issue in my project. Do we already have a workaround?

@rodirigos
Copy link

Any update on this problem?

@MasterOliver21
Copy link

Unfortunately, I am having the same problem and can't find a solution. Any feedback?

@MartyIX
Copy link
Contributor

MartyIX commented Jun 20, 2024

I've been running some tests with WinUI3 and apparently has the same problem, the memory still increasing and never released.

Then it's certainly a good idea to report it in the https://github.com/microsoft/microsoft-ui-xaml repo.

@danielancines
Copy link
Author

danielancines commented Jun 22, 2024

I identify on WindowHandler.Windows.cs class that MauiWinUIWindow still on windowRootContentManager (NavigationRootManager) at _platformWindow field, after clear it using reflection, MauiWinUIWindow instances was collected by GC.

image


Controls.Window still in memory, searching for an workaround to release them

image


My content view still on memory too
image

It appears that dotnet Maui has a lot of Memory Leak points, RAM memory never release.

@danielancines
Copy link
Author

danielancines commented Jun 23, 2024

Cleaning GestureManager from MyView (ContentView) on unload, it was possbile to release some memory and remove all MauiWinUIWindow, Window and my content views instances from memory.

Apparently GestureManager and GesturePlatformManager never been disposed and hold an instance of my view after window closed and view unloaded.

image

@MartyIX
Copy link
Contributor

MartyIX commented Jun 24, 2024

(Perhaps @jonathanpeppers could comment on this one.)

@jonathanpeppers
Copy link
Member

jonathanpeppers commented Jun 26, 2024

I tested the sample, and made the change:

public class MyContentPage : ContentPage
{
	protected override void OnDisappearing()
	{
		base.OnDisappearing();

		GC.Collect();
	}
}

This will just make the GC more deterministic, so the GC runs as you close each Window. (This is just for debugging, remove it from your app when finished testing)

I also subclassed Window, so I could search for it in .gcdump files more easily:

public class FooWindow : Window
{
    public FooWindow() : base (new MyContentPage()) { }
}

Opening many windows, I only see 1 FooWindow alive at a time in a given snapshot:
image

I think it just takes a couple GCs for each Window to go away. I don't think I see a leak here?

I would also verify you have XAML hot reload turned off when testing this, see:

@jonathanpeppers jonathanpeppers added the s/needs-info Issue needs more info from the author label Jun 26, 2024
@danielancines
Copy link
Author

danielancines commented Jun 27, 2024

Hi @jonathanpeppers, thank you for answer me, I made the same code as you, only difference is I run GC.Collect on MainWindow Deactivated and after open new windows, close them, open again I got this result, running in Release:

There's 18 mauiwinuiwindow in memory
image

Actually FooWindows was collected in my tests, but the main problem is, the use of RAM memory still increasing, and this is the problem in my company's application, check this out:

App running:
image

Some windows opened:
image
Some GC.Collect executions:
image
image

More windows:
image

After close them:
image
image

My views has only some labels on it, IMHO, since MauiWinUIWindow still in memory, and task manager doesn't show significant memory decrease, something is not right.

Update:
After a couple of minutes with my app running, and GC executions, memory stil the same on task namager:
image
image

This is the main problem, if user still opening and closing windows, with more complex views, the memory can reach 1gb with only main window running.

image

@dotnet-policy-service dotnet-policy-service bot added s/needs-attention Issue has more information and needs another look and removed s/needs-info Issue needs more info from the author labels Jun 27, 2024
@jonathanpeppers
Copy link
Member

Ok, maybe there is a problem with MauiWinUIWindow:

image

Let me investigate some more, thanks!

@danielancines
Copy link
Author

danielancines commented Jun 27, 2024

Cleaning GestureManager from MyView (ContentView) on unload, it was possbile to release some memory and remove all MauiWinUIWindow, Window and my content views instances from memory.

Apparently GestureManager and GesturePlatformManager never been disposed and hold an instance of my view after window closed and view unloaded.

image

Maybe above there's some insights to help your investigation.

jonathanpeppers added a commit to jonathanpeppers/maui that referenced this issue Jun 27, 2024
Fixes: dotnet#22973
Context: https://github.com/danielancines/memory-leak-dotnet8-maui

After reviewing the above sample app, I found that the
`MauiWinUIWindow` class was not ever going away. I could see it being
held by `NavigationRootManager`:

* `Microsoft.Maui.MauiWinUIWindow` ->
  * `Microsoft.Maui.Platform.NavigationRootManager` ->
    * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>`

After some trial and error, I found that simply changing
`NavigationRootManager`'s `_platformWindow` field a `WeakReference`
"untangles" things, and the sample no longer leaks `MauiWinUIWindow`
instances.

Unfortunately, I was not able to write a passing test for this issue.
No matter what I tried, the platform `Window` is kept alive by a
"strong handle". But taking a snapshot after the test ends, it goes
away?

I still thing the test is useful, as it verifies the other objects.
jonathanpeppers added a commit to jonathanpeppers/maui that referenced this issue Jun 28, 2024
Fixes: dotnet#22973
Context: https://github.com/danielancines/memory-leak-dotnet8-maui

After reviewing the above sample app, I found that the
`MauiWinUIWindow` class was not ever going away. I could see it being
held by `NavigationRootManager`:

* `Microsoft.Maui.MauiWinUIWindow` ->
  * `Microsoft.Maui.Platform.NavigationRootManager` ->
    * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>`

After some trial and error, I found that simply changing
`NavigationRootManager`'s `_platformWindow` field a `WeakReference`
"untangles" things, and the sample no longer leaks `MauiWinUIWindow`
instances.

Unfortunately, I was not able to write a passing test for this issue.
No matter what I tried, the platform `Window` is kept alive by a
"strong handle". But taking a snapshot after the test ends, it goes
away?

I still thing the test is useful, as it verifies the other objects.
jonathanpeppers added a commit to jonathanpeppers/maui that referenced this issue Jul 2, 2024
Fixes: dotnet#22973
Context: https://github.com/danielancines/memory-leak-dotnet8-maui

After reviewing the above sample app, I found that the
`MauiWinUIWindow` class was not ever going away. I could see it being
held by `NavigationRootManager`:

* `Microsoft.Maui.MauiWinUIWindow` ->
  * `Microsoft.Maui.Platform.NavigationRootManager` ->
    * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>`

After some trial and error, I found that simply changing
`NavigationRootManager`'s `_platformWindow` field a `WeakReference`
"untangles" things, and the sample no longer leaks `MauiWinUIWindow`
instances.

Unfortunately, I was not able to write a passing test for this issue.
No matter what I tried, the platform `Window` is kept alive by a
"strong handle". But taking a snapshot after the test ends, it goes
away?

I still thing the test is useful, as it verifies the other objects.
@samhouts samhouts removed s/verified Verified / Reproducible Issue ready for Engineering Triage s/triaged Issue has been reviewed labels Jul 3, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Aug 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-controls-window Window fixed-in-8.0.70 fixed-in-9.0.0-preview.7.24407.4 memory-leak 💦 Memory usage grows / objects live forever (sub: perf) platform/windows 🪟 s/needs-attention Issue has more information and needs another look t/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.