-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Memory leak when VisualElement are no longer in view on Android #21853
Comments
I may be wrong, but I would be surprised if such simple pages still leaked. Have you already seen the following page: Basically what I would try:
As a staring point you can look at my code for another iOS issue: I hope I'm not misguiding you... 😃 |
I added some logging for the deconstructor of the pages: ~Page2()
{
Console.WriteLine("~Page2() called");
} That gets logged when I set the pages to transient - and even when removing the But maybe there are also memory leaks besides pages not being garbage collected...?! |
I don't know if that's even a different problem. But I better leave this to the official .NET MAUI team... |
P.S.: I can imagine this is a desired behavior: Because when removing page by page from the stack, each time the underlying page gets the current one and seemingly "activated". You could prevent this additional calls to |
That is correct but then I need to track how many navigations I did. at the moment we have different pages each making a view for a step that represents the work done in the physical world. this means sometimes we have to prevent "Go Back" by the physical keyboard on the Android device because the workflow can only go forward. since every flow has a different number of steps to process we navigate back to to start when starting a new loop. a "Clear" method can also help. The easy part is that we can set a page as that active view without the shell but if we do that we always have a white blinking screen in between. |
@peirens-bart |
I don't see a leak here. If you want to get the GC to behave deterministically, you need to call GC.Collect() several times. |
sorry same result, can you make on how to do it using and Android emultaor? |
https://github.com/AdamEssenmacher/MemoryToolkit.Maui That might help you track down where your leaks are happening. |
I tried that but nothing came up. @SittenSpynne You nailed it in this discussion #21918 (comment) |
I updated the title and the example project because we investigated the issue on our side and it has nothing to do with navigation but with the visual state of the element.
then Page 4 look like
With a simple timer to create a blinky app
after 5 minutes the memory footprint looks like this, even when I forced a GC via the profiling tool the memory is not like the original when the page was first rendered. |
So, Android Studio's "force a GC button" won't trigger a .NET GC. Android doesn't know what .NET is. I'm reviewing the sample now, though; will report what I find. |
@peirens-bart what object in your sample do you think is leaking? I made these changes to assist debugging this: I see the log message:
Which indicates that The other pages live forever, because you registered them as singletons: builder.Services.AddSingleton<AppShell>();
builder.Services.AddSingleton<MainPage>();
builder.Services.AddSingleton<Page1>();
builder.Services.AddSingleton<Page2>();
builder.Services.AddTransient<Page3>(); What C# object should I be looking for here? I should be able to compare two |
@jonathanpeppers I don't think it is a page that is leaking but the visuals on the page. |
What type do you think is leaking? Namespace and type name? Should I navigate around, or just let the page sit a while blinking? |
Just wait 5 minutes before take the diff, can you share the setup you ar using to see the dump in vs? |
@jonathanpeppers If you have some time we can have a short call about it? |
I am following the guide here, linked from https://aka.ms/profile-maui:
So test But so far it seems fine: I keep waiting, but there are only a few fresh objects until the next GC runs again. |
I followed the same guide but the tool is giving exceptions on my machine
What is the overall memory of the app between dumps, and is it leaking or is something else leaking outside the maui code? |
@jonathanpeppers I see that you are calling gc when the timer is elapsing, is there any reason for that? |
The Here are my two recent dumps after the app sat blinking a while: blinking.zip |
Try these versions:
|
You have any suggestion on the memory, or what I can do? |
A coworker saw this, but reinstalled the dotnet tools, which might have fixed it? (Or could have been just trying again)
I'm not seeing a problem here, maybe you can share what object you see leaking? If you can see something in Android Studio, which object is it? |
That is the thing I don't know. The only thing I can see in Android studio is that the memory is going up. in our production app we even got an OOM after a few hours. but I already added finelizers to all pages and they got hit and I used weakrefs for all events.My gues is that when using an object that is inherithing from 'VisualElement' that the element itself is not totaly disposed. I added the heap dump from Android studio when running blinkt for 5' |
@peirens-bart right, so if we can't see a Microsoft.Maui object alive, it's not an issue with .NET MAUI. This could be an Android bug? Have you had any more luck with |
Can you also test with a physical device instead of an emulator? |
Description
I created pages and navigated from the mainpage to them and back when navigating back the page is removed from the visual tree but the app memory goes up. when I change the page di setup from singleton to transient you see that even the 100Mb that I put on page 2 is not collected from memory when the page is removed from the visual tree, I need to set the variable to null.
so when you have a transient page storing a big variable the page is not collected when removed from the visual tree. when switching to singleton the memory of the app is still growing even if the page is not in the visual tree and should be added once, I think that that the memory can only go up 1 time when the singleton is created.
this is only on Android.
Screenshot navigating from mainpage to page1 and back, you see the grey line going up. this is a problem whit an industrial app we want to make that needs to run 10H. at some point the app is lowing down due to this.
Steps to Reproduce
Link to public reproduction project repository
https://github.com/peirens-bart/MauiMemory
Version with bug
8.0.20 SR4
Is this a regression from previous behavior?
Yes, this used to work in Xamarin.Forms
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
No response
Did you find any workaround?
No, I can make a gcdump (always getting a write error) to see what is it that is stored in memory. My suspension is that the used controls are not disposed.
Relevant log output
No response
The text was updated successfully, but these errors were encountered: