-
Notifications
You must be signed in to change notification settings - Fork 676
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
Navigation Memory Leak #934
Comments
This issue is also cross-posted to https://stackoverflow.com/questions/56675628/uwp-navigation-memory-leak. We can investigate as a platform bug and report back to stack overflow when we understand this. @MikeHillberg can you debug this repro? |
I also have this problem with the same settings cited. |
I leave my comment here, although it's an old post, for others that might search for it. We made huge improvements in memory handeling and GC calls with latest UWP 6.2.9 Nuget update while targeting >=RS4 . The complete release notes are here: https://github.com/microsoft/dotnet/blob/master/releases/UWP/net-native2.2/README.md |
@cheles I am not using WinUI currently, is there a way for me to use these latest changes? |
@Encrypt0r Microsoft.NETCore.UniversalWindowsPlatform is the default package for any UWP application. aren't you using this package? |
@cheles I actually do! Thanks, that's great to hear and I hope you continue these optimizations |
cool. test it and let us know if we can close this one out. |
@cheles unfortunately, it doesn't seem to help with the repro. I have disabled NavigationStack on the frame and yet, no memory is reclaimed after 3 garbage collections. |
Hi ! |
@Encrypt0r are you debugging a Debug build or Release? GC is implemented differently and, in general, it's an expensive. In Release you will see GC being called more rarely than Debug. 93 MB out of, probably 3/4GB or RAM is not dangerously enough to cause GC to clean gen 0/1/2 objects. I've tried your sample in Debug and I've barely got to 80 MB after 80+ clicks. |
Along the lines of what @cheles mentioned, I'd recommend you give this article a read. In particular item 4 of "What Causes Memory Leaks?". |
Also, if you want a more in-depth way to inspect memory consumption & GC calls, use Performance Monitor (Win10 built-in) https://devblogs.microsoft.com/dotnet/gc-performance-counters/ |
@cheles This problem has existed for a long time and has not been solved, even with the updated Microsoft.NETCore.UniversalWindowsPlatform to lastest. |
@CodeForCSharp I haven't said that UWP team fixed all memory issues in UWP. I just said that UWP 6.2.9 brought some memory consumption improvements per this link
dotnet/runtime#12255 seems to have been marked for Future release but I don't see any due date to it. |
@cheles Thank you for your work.I know it's getting better. |
@cheles, I am using latest version 6.2.10, and still facing this memory leak issue, which leads to app memory to 1 GB. |
Why doesn't Microsoft test it and fix it? |
This problem also exists when using C++/WinRT. The destructor does get called when switching pages, but the memory continues to grow. It's disappointing that this bug has not been fixed after three years. |
I have the same problem. When I press the ‘X’ to close the app, the last Page in Frame was not released, the destructor of last Page not called. |
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Hello @garrettpauls I hope you are well.
You need to apply the architecture correctly so you don't have memory leaks. Take this example of architecture. https://github.com/microsoft/InventorySample |
@r7dev where is that documented? Coming from a WPF background unsetting ItemsSource has never been necessary before, and I don't see any indication that should be necessary now according to the documentation for that ItemsControl.ItemsSource or the documentation for ListView (a sample is not documentation)... That said, I did give it a try by manually setting and unsetting ItemsSource, and it does make a difference, however there is still a leak somewhere. Are there other places we're also expected to be manually unsetting values? Is there a way to know what properties need to be manually unset when a page is navigated away from that I can reference?
Thank you for pointing this out, it's frustrating that it doesn't seem documented anywhere, so I appreciate you mentioning it. I'll see if I can get our app to manually clean up all our ItemsSource bindings and hopefully that will improve the situation. |
In case anyone else needs it, I ended up writing a little helper class as a quick fix to this while we evaluate more direct options. I'm calling Here's a simplified version that should be fine for common use: public static class CleanUp
{
public static void FrameworkElement( FrameworkElement element )
{
var count = VisualTreeHelper.GetChildrenCount( element );
for( var index = 0; index < count; index++ )
{
var child = VisualTreeHelper.GetChild( element, index );
if( child is FrameworkElement childElement )
{
FrameworkElement( childElement );
}
}
switch( element )
{
case ItemsControl itemsControl:
itemsControl.ItemsSource = null;
break;
case ItemsRepeater itemsRepeater:
itemsRepeater.ItemsSource = null;
break;
case TabView tabView:
tabView.TabItemsSource = null;
break;
}
}
} then in our shared PageBase class: protected override void OnNavigatedFrom( NavigationEventArgs args )
{
base.OnNavigatedFrom( args );
if( NavigationCacheMode == NavigationCacheMode.Disabled )
{
CleanUp.FrameworkElement( this );
}
} |
Describe the bug
We have noticed that our UWP apps have memory leaks. I have investigated it and found out that when navigating to new pages, the memory gets higher and doesn't seem to go down by much even when GC runs. The pages do get garbage collected (Their finalizer is run), but it seems like some kind of unmanaged memory is not properly cleaned up.
Steps to reproduce the bug
I have put together a small repro that consists of two pages:
The full source code is available on GitHub.
I have also tried out setting Frame.IsNavigationStackEnabled to false, it doesn't help.
What am I doing wrong here?
Expected behavior
Memory is reclaimed after Garbage collector runs
Screenshots
And you can see a video of the repro.
Version Info
NuGet package version:
N/A (Not using WinUI)
Additional context
The text was updated successfully, but these errors were encountered: