[net7.0 / net8.0] [iOS] Memory leak when the CollectionView uses CollectionChanged and when adding a CollectionView to a Page makes it and the entire page live forever

[Sergtek]

Description

I have located a memory leak that occurs when navigating to a page that contains a CollectionView which I have configured with 50 items (3 images are represented for each item and some other simple controls), when navigating to that page an amount of RAM memory is assigned which then it is never released, not even by browsing backwards, which causes the app to end up crashing sooner or later due to lack of RAM memory.

I leave a video where the RAM increases without limit and is never released:
https://www.youtube.com/watch?v=6lf3xWDtXGw

I have tried both on .NET 7 and .NET 8 and the same problem occurs on both.

Steps to Reproduce

• Clone the following repository:
  https://github.com/nacompllo/MemoryLeakEverywhere
• Run the app on an iOS device.
• Have Xcode Instruments open to see how the RAM increases.
• Follow the same steps as in the attached video.

Link to public reproduction project repository

https://github.com/nacompllo/MemoryLeakEverywhere

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

iOS 16

Did you find any workaround?

No response

Relevant log output

No response

Related to

• iOS/Catalyst memory leak with CollectionView when CollectionChanged is used #16125

Depends on

• [controls] fix memory leak in CollectionView #14329

[jsuarezruiz]

cc @jonathanpeppers

[jonathanpeppers]

#14329 was only merged last week, so it has not shipped in .NET 8 yet.

[Sergtek]

#14329 was only merged last week, so it has not shipped in .NET 8 yet.

Good news! Will it come to .NET 7 too?

[QuiqueLargachaGil]

Hi everyone,

I can see that the issue is still in an Open status, but I am writing to provide some feedback just in case it helps.
I have forked the repository indicated by @Nacompllo and I have tested the same application compiling with the version released a few days ago of .Net 8 preview 4. The changes to make the compilation are isolated in two independent branches (one for #14654 and another for #14664). Here is a link to the repository:

https://github.com/QuiqueLargachaGil/MAUI-POC.MemoryLeakEverywhere/tree/bugfix/updated-to-Net-8-preview-4

And the result for the case of this incident is the same. There are still memory leaks when reproducing the issue. I share with you a youtube link to watch the video that shows it.

https://www.youtube.com/watch?v=z2jqwneDjoo&t=62s

Many thanks!

[jonathanpeppers]

Yes, this is not fixed until we get these merged:

• [ios] fix memory leak in Image #15062
• [ios] fix memory leaks in ContentView #15193

But then we'll need to retest the above sample app, to see if there are further issues.

[liveinvarun]

Will there be fix for this issue in Net7? Currently the latest version of the framework has the memory issue on collectionview. Instruments log shows the collectionview presisting issue @jonathanpeppers

[fischberg]

I delayed the release of my app 5 months hoping this would be fixed in the supported release of .NET 8. I tested my app this week using the latest release of MAUI and there's no change in the behavior. Still have this exact same issue. I can only render one of the most important pages in my app 5 times before the app is jettisoned by iOS. On Mac Catalyst, the leak isn't as bad. Some memory seems to be freed each time I pop a page from the navigation stack in Mac Catalyst.

[jonathanpeppers]

@fischberg can you file a new issue with a .gcdump file of your app? https://aka.ms/maui-memory-leaks

This issue has a better list of what controls should be fixed so far:

• Many controls (mainly iOS) are not collected by GC  #18365

(However, some of these fixes are in the upcoming service release)

[ghost]

Hi @Nacompllo. We have added the "s/try-latest-version" label to this issue, which indicates that we'd like you to try and reproduce this issue on the latest available public version. This can happen because we think that this issue was fixed in a version that has just been released, or the information provided by you indicates that you might be working with an older version.

You can install the latest version by installing the latest Visual Studio (Preview) with the .NET MAUI workload installed. If the issue still persists, please let us know with any additional details and ideally a reproduction project provided through a GitHub repository.

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[homeyf]

This is a Memory leak issue, we tried to reproduce it with a user-provided project, and it took over an hour to run. But the memory
consumption is still less than 1GB, so it is marked as not reproduce.

[fischberg]

@jonathanpeppers - I will give it a shot. I've never created a .gcdump fiile before. So, I'll have to do a little learning. I have a simple sample program that reproduces the problem consistently for me using the latest supported MAUI release. You can find it here: https://github.com/fischberg/MemoryLeak. If you build the app, run it in an iOS simulator and hit the "Display Using CollectionView" button over and over, you'll see the total RAM usage continue to build without any noticeable RAM being freed each time the back navigation button "<" is pressed. The "Display Not Using Collection View" builds the ContentPage without using a CollectionView. It takes a few minutes to run, consumes about 10Gb of RAM for each rendering of the data and exhibits the same memory leak behavior as using a CollectionView. The 3rd button implements the same view using a CollectionView with an ObservableCollection and reuses the same ContentPage over and over. That approach is a viable workaround. Unfortunately, in my real app, the CollectionView uses grouped data which isn't being refreshed properly each time the ObservableCollection changes :(.