[ISSUE?] PopupV2 memory leak ? (Windows at least)

[elTRexx]

As I am not 100% it is an issue or not, I ask in discussions instead of opening an issue for now.
Using Popup V2, even when declared as Singleton on built in D.I. services, end up with memory leak from diagnostic chart on Visual Studio 2022.

I simply created a simple Popup with a static (aka no binding) Label, without any linked BindingContext, I have a button that end up getting this simple Popup singleton instance from D.I. services, then call Shell.Current.CurrentPage.ShowPopupAsync(simplePopup);,
does some asynchronous fake processing (just a loop of 'N' await Task.Delay(0, cancellationToken);). Finally I call await simplePopup.CloseAsync();.

It work, but monitoring on release build (without hot reload) inside Visual Studio memory use diagnostic chart, I see my memory "climbing" after each click without being G.C. somehow later.

You can try my test repo if you don't wan't to code yourself (though it is a bit messy as I iterate testing over and over on this). (click on "Test popup" button to land on PopupTestPage, then click several time in a row on "Fake simple processing" button. You can adjust to number of fake process loop in the Entry above.)

Is this an issue, or the expected behavior (or I am doing something wrong in my code) ?

[rokmeglic71]

Could you do a smaller example (smaller repo) or like CoPilot AI said:

1️⃣ Reproduce in a Minimal, Isolated Project
Strip your test repo down to:

One page

One popup

The exact singleton registration you’re using

The same ShowPopupAsync → async work → CloseAsync flow

This ensures you’re not chasing leaks caused by unrelated code.

... it will be much easier to test and isolate the problem.

[elTRexx]

Here you are : https://github.com/elTRexx/PopupV2TEST
I kept it as simple as possible.
You can see it still increase memory usage over clicking on show and auto close singleton popups. :

[pictos]

something looks off

@elTRexx can you please a bug with your sample?

I was faster and furious, here's the fix:

• Fix memory leak on popups #2858

[elTRexx]

Thank you for fast reply / fix.
Bu I am still confused, because to my understanding it is counter intuitive to do this kind of events / bindings cleanup for singletons.

It would perfectly make sense for transient classes, but for singletons, isn't actually its purpose to register the events / bindings once in CTOR (like it is done here), and then don't unregister / cleanup, but instead keep and return the only 1 "static" instance of it afterward ?

[pictos]

What's singleton is your Popup, which is a ContentView... The PopupPage the container that holds your popup isn't singleton, it's transient, and it's just a ContentPage, so every time that you show your popup a new PopupPage is created to show it, and if there's no unhook the popped pages will be alive 4ever.

And tbh, having a reusable PopupPage is harder than just create a new one, normally those pages will live on Gen1 so is cheap.

[elTRexx]

Thank you for your explanation. It make sens this way. Even though I supposed using singleton was always preferable performant wise, maybe some mechanism I'm unaware of behind PopupPage make it indeed harder to maintain it as a singleton.

[pictos]

I supposed using singleton was always preferable performant wise

If the object is easy to create having a singleton can be bad, for a lot of reasons, there's no silver bullet on that. In this particular case the reason is the way the control was built. IT would be fine to have a pool of PopupPage and reuse then, but it will need more code to clean up the PopupPage to accept a new Popop content. In multiWindow app you the same PopupPage or even Popup can be shown in different Windows so you need to create one per window, which would add more complexity to our pool. I hope this simple idea could answer why, in our case, create a new is easier