[net7.0 / net8.0] [iOS] Memory leak when CollectionView.ItemsSource changes #14664

Sergtek · 2023-04-19T15:14:38Z

Description

I am aware of the existence of the following bug #13530 but only mention is made of Windows, however in iOS the same memory leak problem also occurs when updating the ItemsSource of a CollectionView several times and the RAM memory is not released even by browsing backwards:

I leave a video playing an example repository where I can reproduce this problem in iOS until the application crashes due to lack of memory:
https://www.youtube.com/watch?v=_UTEGbE4-ug

I leave the repository that I show in the video so you can do the test:
https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource

Steps to Reproduce

Clone the following repository:
https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource
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/tree/bugfix/memoryLeakItemsSource

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

Depends on

drasticactions · 2023-04-19T15:34:28Z

How is this different from #14654, which is not closed?

Sergtek · 2023-04-19T15:38:44Z

How is this different from #14654, which is not closed?

The #14654 is about a memory leak when repeatedly navigating between pages and #14664 is a memory leak when the ItemsSource from CollectionView changes.

jonathanpeppers · 2023-05-09T14:36:33Z

@Nacompllo and you were testing this on .NET 7?

It might be fixed by this one, which is only in main/.NET 8 currently:

[controls] fix memory leak in CollectionView #14329

I will test your above sample, though, thanks.

jonathanpeppers · 2023-05-09T14:39:55Z

Note that my comment here:

Is specifically talking about a list of "logical children" that grew indefinitely on Windows.

jonathanpeppers · 2023-05-09T16:37:13Z

There appears to be an issue with images on iOS, a failing test:

[Fact("Image Does Not Leak")]
public async Task DoesNotLeak()
{
	SetupBuilder();
	WeakReference reference = null;

	await InvokeOnMainThreadAsync(async () =>
	{
		var layout = new VerticalStackLayout();
		var image = new Image
		{
			Background = Colors.Black,
			Source = "red.png",
		};
		layout.Add(image);

		var handler = CreateHandler<LayoutHandler>(layout);
		await image.Wait();
		reference = new WeakReference(image.Handler.PlatformView);
	});

	await Task.Yield();
	GC.Collect();
	GC.WaitForPendingFinalizers();
	
	Assert.NotNull(reference);
	Assert.False(reference.IsAlive, "PlatformView should not be alive!");
}

Still investigating what the fix would be.

Context: dotnet#14664 (comment) `Image` has two different "cycles" on iOS: * `ImageHandler` -> `MauiImageView` -> `ImageHandler` * via the `WindowChanged` event * `ImageHandler` -> `ImageSourcePartLoader` -> `ImageHandler` * via `Handler`, `Func<IImageSourcePart?>`, and `Action<PlatformImage?>` This causes any `MauiImageView` to live forever. To solve these issues: * Get rid of the `MauiImageView.WindowChanged` event, and use a `WeakReference` to the handler instead. * `ImageSourcePartLoader` now only has a `WeakReference` to the handler. * This requires a new `ISetImageHandler` interface to be used by several handler types involving images. Hopefully the changes here are using `[Obsolete]` correctly to make things backwards compatible & less breaking changes. Unsure yet if this fully solves dotnet#14664, but at least one part of it.

Context: https://github.com/jonathanpeppers/MemoryLeaksOniOS Related to: dotnet#14664 There are a couple cycles on iOS that causes memory leaks in all controls based on `ContentView`: * `Microsoft.Maui.Controls.ContentView` -> * `ContentViewHandler` -> * `Microsoft.Maui.Platform` -> * `CrossPlatformArrange/Measure` property -> * `Microsoft.Maui.Controls.ContentView` cycle To fix this, I made `CrossPlatformArrange/Measure` properties obsolete, using the weak `View` property directly instead. This applies to various other controls like `Border`, `RadioButton`, `SwipeItemView`, `SwipeView`. I did not yet fix `ScrollView` that appears to be more complicated to solve. For now, it supports both code paths. `ScrollView` will continue to have leaks in: * Closures with captured variables * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L195 * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L227 * `CrossPlatformArrange/Measure` * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L182-L186

QuiqueLargachaGil · 2023-05-29T14:05:46Z

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-in-memoryLeakItemsSource-branch

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=EAxcUQE6wLE

Many thanks!

jonathanpeppers · 2023-05-30T14:41:31Z

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

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

Context: https://github.com/jonathanpeppers/MemoryLeaksOniOS Related to: dotnet#14664 There are a couple cycles on iOS that causes memory leaks in all controls based on `ContentView`: * `Microsoft.Maui.Controls.ContentView` -> * `ContentViewHandler` -> * `Microsoft.Maui.Platform` -> * `CrossPlatformArrange/Measure` property -> * `Microsoft.Maui.Controls.ContentView` cycle To fix this, I made `CrossPlatformArrange/Measure` properties obsolete, using the weak `View` property directly instead. This applies to various other controls like `Border`, `RadioButton`, `SwipeItemView`, `SwipeView`. I did not yet fix `ScrollView` that appears to be more complicated to solve. For now, it supports both code paths. `ScrollView` will continue to have leaks in: * Closures with captured variables * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L195 * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L227 * `CrossPlatformArrange/Measure` * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L182-L186

Context: dotnet#14664 (comment) `Image` has two different "cycles" on iOS: * `ImageHandler` -> `MauiImageView` -> `ImageHandler` * via the `WindowChanged` event * `ImageHandler` -> `ImageSourcePartLoader` -> `ImageHandler` * via `Handler`, `Func<IImageSourcePart?>`, and `Action<PlatformImage?>` This causes any `MauiImageView` to live forever. To solve these issues: * Get rid of the `MauiImageView.WindowChanged` event, and use a `WeakReference` to the handler instead. * `ImageSourcePartLoader` now only has a `WeakReference` to the handler. * This requires a new `ISetImageHandler` interface to be used by several handler types involving images. Hopefully the changes here are using `[Obsolete]` correctly to make things backwards compatible & less breaking changes. Unsure yet if this fully solves dotnet#14664, but at least one part of it.

Context: https://github.com/jonathanpeppers/MemoryLeaksOniOS Related to: dotnet#14664 There are a couple cycles on iOS that causes memory leaks in all controls based on `ContentView`: * `Microsoft.Maui.Controls.ContentView` -> * `ContentViewHandler` -> * `Microsoft.Maui.Platform` -> * `CrossPlatformArrange/Measure` property -> * `Microsoft.Maui.Controls.ContentView` cycle To fix this, I made `CrossPlatformArrange/Measure` properties obsolete, using the weak `View` property directly instead. This applies to various other controls like `Border`, `RadioButton`, `SwipeItemView`, `SwipeView`. I did not yet fix `ScrollView` that appears to be more complicated to solve. For now, it supports both code paths. `ScrollView` will continue to have leaks in: * Closures with captured variables * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L195 * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L227 * `CrossPlatformArrange/Measure` * https://github.com/dotnet/maui/blob/3b620952425ca3c4542c4632e05d09eb4f583e22/src/Core/src/Handlers/ScrollView/ScrollViewHandler.iOS.cs#L182-L186

Context: dotnet#14664 (comment) `Image` has two different "cycles" on iOS: * `ImageHandler` -> `MauiImageView` -> `ImageHandler` * via the `WindowChanged` event * `ImageHandler` -> `ImageSourcePartLoader` -> `ImageHandler` * via `Handler`, `Func<IImageSourcePart?>`, and `Action<PlatformImage?>` This causes any `MauiImageView` to live forever. To solve these issues: * Get rid of the `MauiImageView.WindowChanged` event, and use a `WeakReference` to the handler instead. * `ImageSourcePartLoader` now only has a `WeakReference` to the handler. * This requires a new `ISetImageHandler` interface to be used by several handler types involving images. Hopefully the changes here are using `[Obsolete]` correctly to make things backwards compatible & less breaking changes. Unsure yet if this fully solves dotnet#14664, but at least one part of it.

* [ios] fix memory leak in Image Context: #14664 (comment) `Image` has two different "cycles" on iOS: * `ImageHandler` -> `MauiImageView` -> `ImageHandler` * via the `WindowChanged` event * `ImageHandler` -> `ImageSourcePartLoader` -> `ImageHandler` * via `Handler`, `Func<IImageSourcePart?>`, and `Action<PlatformImage?>` This causes any `MauiImageView` to live forever. To solve these issues: * Get rid of the `MauiImageView.WindowChanged` event, and use a `WeakReference` to the handler instead. * `ImageSourcePartLoader` now only has a `WeakReference` to the handler. * This requires a new `ISetImageHandler` interface to be used by several handler types involving images. Hopefully the changes here are using `[Obsolete]` correctly to make things backwards compatible & less breaking changes. Unsure yet if this fully solves #14664, but at least one part of it. * Update src/Core/src/Platform/ImageSourcePartLoader.cs Co-authored-by: Matthew Leibowitz <mattleibow@live.com> * Update MauiImageView.cs * Update MauiImageView.cs * ISetImageHandler -> IImageSourcePartSetter * IImageHandler.OnWindowChanged() is now public * Fix IImageSourcePartSetter namespace * MauiImageView._handler can be readonly --------- Co-authored-by: Matthew Leibowitz <mattleibow@live.com>

Context: dotnet#14664 Context: https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource In reviewing our latest changes in main with the above customer sample, I found that there appeared to be leaks related to MAUI's `UITableViewCell` subclasses when using `CollectionView`. I was able to reproduce the issue in a test, such as: // DataTemplate saves WeakReference to the View in a list collectionView.ItemTemplate = new DataTemplate(() => { var label = new Label(); labels.Add(new(label)); return label; }); // Create a cell and bind it to the template: cell = new VerticalCell(CGRect.Empty); cell.Bind(collectionView.ItemTemplate, bindingContext, collectionView); // Check we have no leaks foreach (var reference in labels) { Assert.False(reference.IsAlive, "View should not be alive!"); } After isolating the issue, I found the issue was the `TemplatedCell.PlatformHandler` property: internal IPlatformViewHandler PlatformHandler { get; private set; } This stores a copy of the `LabelHandler` in our test/example. The problem with `UITableViewCell` is that UIKit holds onto these and reuses them. This means that UIKit may keep the `LabelHandler` alive longer than needed. It also appears to be a somewhat complex circular reference: * `CollectionView` -> handlers / etc. -> `TemplatedCell` -> `LabelHandler` -> `Label` -> `CollectionView` I made the `PlatformHandler` use a `WeakReference` as its backing field and the problem goes away! I will retest dotnet#14664 to verify if it is fully solved.

Context: #14664 Context: https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource In reviewing our latest changes in main with the above customer sample, I found that there appeared to be leaks related to MAUI's `UITableViewCell` subclasses when using `CollectionView`. I was able to reproduce the issue in a test, such as: // DataTemplate saves WeakReference to the View in a list collectionView.ItemTemplate = new DataTemplate(() => { var label = new Label(); labels.Add(new(label)); return label; }); // Create a cell and bind it to the template: cell = new VerticalCell(CGRect.Empty); cell.Bind(collectionView.ItemTemplate, bindingContext, collectionView); // Check we have no leaks foreach (var reference in labels) { Assert.False(reference.IsAlive, "View should not be alive!"); } After isolating the issue, I found the issue was the `TemplatedCell.PlatformHandler` property: internal IPlatformViewHandler PlatformHandler { get; private set; } This stores a copy of the `LabelHandler` in our test/example. The problem with `UITableViewCell` is that UIKit holds onto these and reuses them. This means that UIKit may keep the `LabelHandler` alive longer than needed. It also appears to be a somewhat complex circular reference: * `CollectionView` -> handlers / etc. -> `TemplatedCell` -> `LabelHandler` -> `Label` -> `CollectionView` I made the `PlatformHandler` use a `WeakReference` as its backing field and the problem goes away! I will retest #14664 to verify if it is fully solved.

Context: dotnet#14664 Context: https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource While looking at the customer sample, we found an issue with `BorderHandler`: * `ContentView` -> via `LayoutSubviewsChanged` * `BorderHandler` -> * `ContentView` Creating a cycle & memory leak on iOS and Catalyst. We could reproduce this in a device test. It appears the event only did this: void OnLayoutSubviewsChanged(object? sender, EventArgs e) { PlatformView?.UpdateMauiCALayer(); } And so instead, we can just call the extension method directly: this.UpdateMauiCALayer(); And the leak is gone! Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>

Context: #14664 Context: https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource While looking at the customer sample, we found an issue with `BorderHandler`: * `ContentView` -> via `LayoutSubviewsChanged` * `BorderHandler` -> * `ContentView` Creating a cycle & memory leak on iOS and Catalyst. We could reproduce this in a device test. It appears the event only did this: void OnLayoutSubviewsChanged(object? sender, EventArgs e) { PlatformView?.UpdateMauiCALayer(); } And so instead, we can just call the extension method directly: this.UpdateMauiCALayer(); And the leak is gone! Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>

I added some logging for the sample: * dotnet#14664 * https://github.com/nacompllo/MemoryLeakEverywhere/tree/bugfix/memoryLeakItemsSource I found the "logical children" grow indefinitely on iOS/Catalyst, after adding some logging it quickly got up to 71 items: 2023-07-06 09:04:27.745 MemoryLeakEverywhere[93127:7440192] Microsoft.Maui.Controls.CollectionView added child -> Microsoft.Maui.Controls.Image, count: 71 I was able to reproduce in a test, after I added some code to allow the `CollectionView` to create items (using `WidthRequest`/`HeightRequest`). When you replace an `ItemsSource` on iOS, in this way: var newCollection = new ObservableCollection<string>(); collectionView.ItemsSource = newCollection; foreach (var item in data) { newCollection.Add(item); } It appears that the old items are not removed, the test fails with: Expected: 3 Actual: 6 But passes on Windows & Android. Somewhere, we need to call one of: * `ItemsView.ClearLogicalChildren()` * `ItemsView.RemoveLogicalChild()` But I've not been successful yet.

jonathanpeppers · 2023-07-07T14:11:03Z

The list of linked PRs above address various memory issues found the in above sample. However, the memory still appears to grow in the sample with dotnet/maui/main at this time.

Latest Issue

I found the "logical children" grow indefinitely on iOS/Catalyst, after adding some logging the sample above quickly got up to 71 items:

2023-07-06 09:04:27.745 MemoryLeakEverywhere[93127:7440192] Microsoft.Maui.Controls.CollectionView added child -> Microsoft.Maui.Controls.Image, count: 71

I can illustrate the issue in this test:

jonathanpeppers@bbea059

It passes on Windows & Android, but on iOS & Catalyst the list of logical children grows.

It appears to be due to this pattern:

var newCollection = new ObservableCollection<string>();
collectionView.ItemsSource = newCollection;
foreach (var item in data)
{
    newCollection.Add(item);
}

If I change it to set ItemsSource last, it also works around this issue:

var newCollection = new ObservableCollection<string>();
foreach (var item in data)
{
    newCollection.Add(item);
}
collectionView.ItemsSource = newCollection;

This version is faster anyway, but the issue seems to be related to the CollectionChanged event firing.

Workarounds for Above Sample

Set ItemsSource or data-bound properties last and do not rely as much on CollectionChanged
- Example:
  jonathanpeppers/nacompllo-MemoryLeakEverywhere@117e3af
We noticed the images in each row were quite large: larger than the area they occupy on screen. We recommend setting BaseSize, so that less memory is used for these images.
- Example (I just chose a number):
  jonathanpeppers/nacompllo-MemoryLeakEverywhere@00a57aa

ghost · 2024-01-04T08:54:03Z

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 · 2024-01-04T08:54:14Z

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.

Sergtek added the t/bug Something isn't working label Apr 19, 2023

Eilon added legacy-area-perf Startup / Runtime performance area-controls-collectionview CollectionView, CarouselView, IndicatorView labels Apr 19, 2023

SarthakB26 mentioned this issue May 9, 2023

Memory Leak with CollectionView #14993

Open

samhouts added the partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with label May 9, 2023

jonathanpeppers self-assigned this May 9, 2023

samhouts added the p/1 Work that is important, and has been scheduled for release in this or an upcoming sprint label May 10, 2023

jonathanpeppers mentioned this issue May 12, 2023

[ios] fix memory leak in Image #15062

Merged

jonathanpeppers mentioned this issue May 19, 2023

[ios] fix memory leaks in ContentView #15193

Closed

samhouts added this to the .NET 8 milestone May 25, 2023

QuiqueLargachaGil mentioned this issue May 29, 2023

[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 #14654

Closed

2 tasks

jonathanpeppers mentioned this issue Jun 22, 2023

Formalize virtual layout concepts and fix iOS memory leaks #15303

Merged

jonathanpeppers mentioned this issue Jun 23, 2023

[ios] fix memory leak in CollectionView cells #15831

Merged

jonathanpeppers mentioned this issue Jun 30, 2023

[ios] fix memory leak in Border #15946

Merged

jonathanpeppers mentioned this issue Jul 5, 2023

[core] fix memory leaks in bindings #13327

Merged

samhouts modified the milestones: .NET 8, .NET 8 GA Jul 12, 2023

samhouts added the memory-leak 💦 Memory usage grows / objects live forever label Aug 1, 2023

samhouts mentioned this issue Sep 5, 2023

[iOS] Clear BindingContext when cell is queued for reuse #14619

Merged

samhouts modified the milestones: .NET 8 GA, .NET 8 + Servicing Sep 12, 2023

samhouts modified the milestones: .NET 8 + Servicing, .NET 8 SR2 Oct 3, 2023

homeyf added s/triaged Issue has been reviewed s/try-latest-version Please try to reproduce the potential issue on the latest public version labels Jan 4, 2024

ghost closed this as completed Jan 11, 2024

samhouts added the platform/iOS 🍎 label Feb 1, 2024

github-actions bot locked and limited conversation to collaborators Mar 3, 2024

Eilon added t/perf The issue affects performance (runtime speed, memory usage, startup time, etc.) and removed legacy-area-perf Startup / Runtime performance labels May 10, 2024

samhouts added delighter-sc and removed delighter-sc labels Jun 17, 2024

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[net7.0 / net8.0] [iOS] Memory leak when CollectionView.ItemsSource changes #14664

[net7.0 / net8.0] [iOS] Memory leak when CollectionView.ItemsSource changes #14664

Sergtek commented Apr 19, 2023 •

edited

Loading

drasticactions commented Apr 19, 2023

Sergtek commented Apr 19, 2023

jonathanpeppers commented May 9, 2023

jonathanpeppers commented May 9, 2023

jonathanpeppers commented May 9, 2023

QuiqueLargachaGil commented May 29, 2023

jonathanpeppers commented May 30, 2023

jonathanpeppers commented Jul 7, 2023

ghost commented Jan 4, 2024

homeyf commented Jan 4, 2024

[net7.0 / net8.0] [iOS] Memory leak when CollectionView.ItemsSource changes #14664

[net7.0 / net8.0] [iOS] Memory leak when CollectionView.ItemsSource changes #14664

Comments

Sergtek commented Apr 19, 2023 • edited Loading

Description

Steps to Reproduce

Link to public reproduction project repository

Version with bug

Last version that worked well

Affected platforms

Affected platform versions

Did you find any workaround?

Relevant log output

Depends on

drasticactions commented Apr 19, 2023

Sergtek commented Apr 19, 2023

jonathanpeppers commented May 9, 2023

jonathanpeppers commented May 9, 2023

jonathanpeppers commented May 9, 2023

QuiqueLargachaGil commented May 29, 2023

jonathanpeppers commented May 30, 2023

jonathanpeppers commented Jul 7, 2023

Latest Issue

Workarounds for Above Sample

ghost commented Jan 4, 2024

homeyf commented Jan 4, 2024

Sergtek commented Apr 19, 2023 •

edited

Loading