Major Memory Leak on Maccatalyst in .NET 9 & 10 Compared to .NET8

[mbolt11]

Description

Hello,

I have a Maui-Blazor Hybrid application that I recently updated from .NET8 to .NET10. My app is a device dashboard that is constantly updating and displays images, plots (using Plotly.Blazor) and data in real time. When I did this update, I noticed the .net10.0-maccatalyst deployment of my app was suddenly leaking memory at a much faster rate than when it was built for .net8.0-maccatalyst. In order to try and narrow down where the leak was coming from, I checked:

• When I deployed the exact same code as a pure Blazor Server application, without the Maui wrapper, I do not see the same memory leak on MacOS or Windows.
• When I deploy the exact same code as a Maui Windows application, I do not see the same memory leak.

I also ran a test where I took the exact same application code and built the Maui-Maccatalyst app for 3 different target frameworks: .net8-maccatalyst, .net9-maccatalyst and .net10-maccatalyst. I then ran the 3 apps simultaneously for 5 hours. At the end of the 5 hours, the memory usage for each version was:

.NET8 --> 445 MB
.NET9 --> 18.34 GB (!)
.NET10 --> 17.88 GB (!)

The only delta between these 3 deployments was the target framework, and the versions of the below workloads & packages:

Workload / Package Name	.NET8 Deployment Version	.NET9 Deployment Version	.NET10 Deployment Version
.NET SDK	8.0.416	9.0.300	10.0.103
Maui SDK	8.0.100	9.0.120	10.0.20
maccatalyst	8.0.400	26.0.9785/9.0.100	26.2.10197/10.0.100
Microsoft.Maui.Controls	8.0.100	9.0.120	10.0.30
Microsoft.AspNetCore.Components.WebView.Maui	8.0.100	9.0.120	10.0.30
Microsoft.Extensions.Configuration.Abstractions	8.0.0	9.0.9	10.0.2
Microsoft.AspNetCore.Components.Web	8.0.14	9.0.9	10.0.2
Microsoft.JSInterop	8.0.14	9.0.9	10.0.2
CommunityToolkit.Maui	8.0.1	12.3.0	14.0.0
CommunityToolkit.Maui.Core	8.0.1	12.3.0	14.0.0

I have attempted a number of strategies to try and profile my app's memory when running via maccatalyst, to see what structures are dominating the leak, but to no real avail so far. I can't get dotnet-trace or dotnet-gcdump to attach to the app when running in maccatalyst, even with setting DOTNET_DiagnosticPorts. The JetBrains dotTrace tool will not attach to it either. The Xcode "Leaks" instrument will attach and collect memory data, but its extremely low-level and opaque -- pretty much all I can see there are a bunch of leaked Malloc mostly from do_icall and I can't figure out what .NET objects they represent.

I know this is not much specific to go on -- I'll continue to try and narrow down this issue, but please let me know if you have any suggestions of what I can try or what information I can provide.

Steps to Reproduce

I don't have a great way to reproduce all the leakage that is happening with my application, but the behavior is observable on a smaller level by doing this:

On MacOS

1. Create a new Maui Blazor Hybrid app using the template from .NET8 SDK
2. Create a new Maui Blazor Hybrid app using the template from .NET10 SDK
3. Modify the Counter.razor in each app such that when the button is clicked, it will start a continuous task in which the counter is incremented and InvokeAsync(StateHasChanged) is called in a loop until cancelled.
4. Run the MacOS configuration of both apps, and record the initial memory usage from Activity Monitor.
5. Click the button to start incrementing counter in both apps at close to the same time.
6. Let the apps run for a few hours. Observe that the rate of memory increase on the .NET10 app is greater than the rate of increase for the .NET8 app. For me, after a little over an hour, the .NET10 app had grown by 7.7MB and the .NET8 app by only 5.3MB

Link to public reproduction project repository

No response

Version with bug

10.0.30

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

.NET 8 (Please specify exact version)

Affected platforms

macOS

Affected platform versions

net9.0-maccatalyst, net10.0-maccatalyst

Did you find any workaround?

No response

Relevant log output

[pictos]

@mbolt11 can you create a small repro so I can look into it? Or share a memory dumb

[mbolt11]

@pictos I finally figured out how to collect a memory dump using the workarounds here

MemoryTrace.zip

[mbolt11]

@pictos Also here are a couple of gcdump files taken a few minutes apart

gcdumps.zip

[pictos]

@mbolt11 since the PR didn't fix I'll take a look at your dump...

What I found was:

System.Double<,,> arrays held in a dictionary on WavefrontDataProcessor, and that processor (and the dictionary/arrays) are being kept alive by the Maui DI root (Microsoft.Maui.MauiContext.KeyedWrappedServiceProvider / ServiceProvider / AppDelegate).

I'm not sure if this one is related with your application (I don't have any expertise on maui-blazor). But if you access to the WavefrontDataProcessor you may want to clean that up manually.

The one on Maui's side could be the render artifacts (RenderTreeFrame[], RenderTreeBuilder, ComponentState, lots of System.Object[]).

Does it rings a bell for you?

[mbolt11]

Hey @pictos , thanks for the analysis!

The System.Double<,,> arrays in WavefrontDataProcessor are a part of my application code -- these are large heavy datasets which I do expect to take a lot of application memory, though I expect they should mostly stop growing after reaching their max. And I don't think they are growing indefinitely: when I baseline the 20260226_112457_20850.gcdump against the 20260226_111730_20850.gcdump, the reference count & size of those objects hasn't grown. But I'm still new to analyzing these files so I may be misinterpreting.

What keeps baffling me is the fact that without changing any of my application code (responsible for WavefrontDataProcessor and Viewer.Shared.UI paths) nor nuget packages (responsible for Telerik and Plotly paths), simply updating from the net8.0-maccatalyst target to net10.0-macatalyst (and the corresponding packages listed in the table above) results in this leak. And, the leak is not seen with the same code built for net10.0-windows10.0.19041.0. Maybe there is something that was somehow being automatically cleaned up in 8 that I now need to manually address in 10?

Today I will try to collect a gcdump file from the .net8 app at the same time as one from the .net10 app and share -- I think comparing those two side-by-side could help us figure out which objects are piling up in the latter.

[mbolt11]

@pictos

I ran another test of the net8 / net10 builds side-by-side for about 28 min. These are the results using memory usage as reported by Activity Monitor:

Target	Memory After Initial Load	Memory After 28 min Running	Growth
net8.0-maccatalyst	234.5 MB	273 MB	38.5 MB
net10.0-maccatalyst	192.6 MB	549.8 MB	357.2 MB

I also collected 2 gcdump's of each version of the app, one shortly after loading and one at the end of the 28 min. Those files are attached in the zip. From an initial look, its a little confusing because the total heap size reported in the gcdump for the .net8 app at the end of the test is higher than what is reported for the .net10 app. It feels like we are not getting the full picture in these dump files. Does that suggest an unmanaged memory leak? What layer would an unmanaged memory leak point to?

gcdumps_compare.zip