microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.35k stars 678 forks source link

Memory leak in NavigationView even though I cleared the child page element while unloading. #5978

Open prabakaran-sangameswaran opened 3 years ago

prabakaran-sangameswaran commented 3 years ago

Discussion: Why memory leak occurs while displaying a custom code snippets view in a NavigationView's child page.

Describe the bug

While using the NavigationView control to navigate child pages, the child page's elements were cleared in its own unloading methods. But, the child pages retaining their memory after closing them.

Steps to reproduce the bug

  1. Open and build the sample App8.zip with x86 or x64 architecture.
  2. To take a memory leak report, click the Debug menu item and select the Performance Profiler in Visual studio.
  3. Select theMemory Usage check box and click Start button
  4. Visual studio will start the diagnostic session and launching the application
  5. Click the TakeScreenshot button in the Visual Studio diagnostic session.
  6. Click on the DemoList Navigation Menu Item in the application.
  7. Click on the Code Snippets1 grid view item and its opens a code snippets page
  8. Click on the Back app bar button
  9. Repeat steps 7 and 8 for CodeSnippets 2andCodeSnippets 3
  10. Click the Empty Page Navigation Menu Item.
  11. Wait for 2 min and click the Force GC in the Visual Studio diagnostic session.
  12. Click the TakeScreenshot button in the Visual Studio diagnostic session.
  13. Then, click the Stop Collection

ezgif com-gif-maker (9)

Memory leak report:

image

image

Expected behavior

Memory should be the same or low as the initial screenshot.

Version Info

NuGet package version: [WinUI 3 - Windows App SDK 0.8: 0.8.1]

Windows app type

WinRT

Windows version

October 2020 Update (19042)

Related Links

seven-mile commented 3 years ago

I also inspected this issue several days ago, the mem usage and heap analysis was similar to yours. My env is 22000 + experimental1. WinUI3 indeed has many performance problems to solve.

dylech30th commented 3 years ago

My case with this issue is more severe that what's inside the GridView is tons of Image each of which is bearing a BitmapImage as its source. And I found that the memory usage stays high even if I have cleared the item source of that GridView and confirmed multiple times that there are no other references to prevent the items from begin collected. I run both managed and native profiling several times and, initially, I thought this was a WinRT issue that the BitmapImage can't free up its resource correctly since the issue is immediately resolved once we changed the BitmapImage to SoftwareBitmap and handled the disposal of it manually.

gaetandezeiraud commented 3 years ago

On my side, I just use Navigate with WinUI 0.8.5 on a Frame. And memory grow every time Navigate is call. Don't know if I don't use correctly on my side. But clearly a memory leak.

Simple reproduction: https://discord.com/channels/372137812037730304/580484525075857428/902663747091460147

prabakaran-sangameswaran commented 2 years ago

Hi Team,

Any update on this?

bogdan-patraucean commented 2 years ago

I have the same problem with .NET 6 and Windows App SDK 1.0. The memory is not released after I leave a page, and when I come back it's increasing with the amount needed for the page. If the memory needed for that page is 50 MBs, each time I navigate back and forth, it keeps increasing with 50 MBs. The page constructor is never hit.

wbokkers commented 2 years ago

Even when NavigatioView is used with controls (and not with a Page), the memory used by these controls will not be released after closing the NavigationView. I tested with the NavigationView in its own UserControl. On 'navigation', I set the Visibility of UI elements in a to Visible and Collapsed. So no actual navigation occurs. When I unload the NavigationView, the memory is not released. I see users getting an out of memory exception quite often now that I use NavigationView in our app.

Dimigergo commented 2 years ago

Any update? It's a serious bug, I think.

bogdan-patraucean commented 1 year ago

It should be fixed in the latest WindowsAppSDK version. I tested navigating back & forth and it's indeed increasing the memory but for my app it stops at around 500 MB of RAM. As far as I know there is a cache limit until which no memory will be released, so probably that's why it's still increasing.

brandon3343 commented 1 year ago

Is this issue not a high priority? "WinUI 3 Gallery" and "PowerToys" also has this problem(WinAppSDK: 1.2).

vfib commented 1 year ago

Any news on this? Otherwise, where can I look to get updates for this? Created a WinUI 3, version 1.3, app with the template studio under win 11 and memory is increasing after each menu change. @bogdan-patraucean I might not be up to date in C# and .NET, but 500 MB full of items not needed sounds kind of unpleasent for me. Where are the times youd want a app that uses as little memory as possible?

brandon3343 commented 1 year ago

@vfib memory usage still increase when more than 500 MB, but the growth will slow down. if you continue navigation, your app will crash. (tested with WinAppSDK 1.3)

Powertoys can be used for testing, navigated to difference page many times, Powertoys will crash.

Temporary solutions is:

private void ContentFrame_Navigated(object sender, NavigationEventArgs e)
{
    System.GC.Collect();
}
vfib commented 1 year ago

@l619534951 Yeah, there seem to be some problems with navigation right now. Offtopic, but setting a ThemeResource to create a card like stackpanel in settings page causes my app to crash under certain circumstances after third navigation back and forth. But thanks for that workaround!

AdriaanLarcai commented 1 year ago

Years later this is still an issue from UWP days... Is this something that can actually be solved? Or should we rather undertake the massive effort to move our years-in-the-making application to a different platform?

ranjeshj commented 1 year ago

We've made leak fixes in the recent 1.4 WASDK release. Please give the latest build a try and let us know if this is still an issue. Memory growth is expected until GC kicks in. If you see unbounded growth or leak in a native app, please let us know.

marwalsch commented 1 year ago

@ranjeshj I have updated to 1.4.231008000 and don't see any difference whatsoever. The GC barely cleans up anything at all. Memory build-up diminishes when approaching the 500 MB mark but it will inevitably overflow. This is still a huge issue and should be re-opened

sude22 commented 11 months ago

It really is a great misfortune that such a central function as navigation still does not work without errors. It is not possible to develop professional applications with the WinAppSdk in its current state. The memory leak in the navigation in combination with the use of the WebView2 control (a new instance is created with every page change) causes every application to crash after a few days of use. I hate to think back to the day over a year ago when our team made the decision to build a new LOB application based on WinUI3.

Sahil12524 commented 8 months ago

@vfib memory usage still increase when more than 500 MB, but the growth will slow down. if you continue navigation, your app will crash. (tested with WinAppSDK 1.3)

Powertoys can be used for testing, navigated to difference page many times, Powertoys will crash.

Temporary solutions is:

private void ContentFrame_Navigated(object sender, NavigationEventArgs e)
{
    System.GC.Collect();
}

The official clock app image is also crashing when navigating different pages. The memory never releases and getting increased again and again. even settings of windows 11 is having memory leak image the memory never gets freed!

jeffintc commented 7 months ago

Is there any news on this? It still seems to be occurring with WinApp 1.5 (and .NET 8) with a sample app I created.

LucaCris commented 5 months ago

Confirmed also with VS 17.10

Tiktack commented 2 months ago

Still reproducible with latest WinUI3 Gallery. Spawning additional windows from "Multiple Windows" menu and closing them not releases memory to initial state. 3 years and issue still not addressed....