You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any contents in a Grid will slowly leak if garbage collection is allowed to run without ever being manually called with GC.Collect().
The app will eventually crash when navigating to and away from the page with the Grid; how fast depending on how big, memory-wise, the objects in the Grid are.
Observing the native memory in XCode Instruments reveals garbage collection running and collecting most, but not all, native memory of the type(s) in the Grid, e.g. MauiImage or MauiLabel.
If GC.Collect is called manually, however, the leak does not appear to occur and the app never crashes, nor do I see the same consistent overall memory growth as I do when the garbage collector runs on its own according to its algorithm.
No managed memory leak is observed according to memory usage reported by the GC API.
Reproduction Steps
Open the attached test project
Deploy release configuration to iPad device (leak occurs on simulator as well, but Instruments and the simulator crash due to low system memory before the app crashes)
Open Instruments app with Leaks profiles
Attach to the installed test app in the iPad and record to launch and profile the app
App will continue to run indefinitely without out of memory native crash.
Actual behavior
App crashes with native out of memory error.
It will take about an hour as is. Right now the Label is the only content of the Grid.
Add the commented images back in and the app will crash much faster.
See comments in GridLeakPage.xaml:
Wrap a large Image in a Grid, and it will crash in about 14 minutes (iPad Pro)
Add one more of the same and it will crash in about 7 minutes
Add 3 more and it will crash in about 3.5
Even a Label leaks. Comment out the images and comment in the Labels and the app will crash in a bit more than an hour.
If GC.Collect is called manually, leak does not occur.
Regression?
Unknown
Known Workarounds
Manually call GC.Collect() when navigating away from the page with the Grid.
Configuration
.NET 8 MAUI
iOS 17.5.1
ARM64
Issue does not occur on Android using .NET 8 MAUI
Other information
I discovered that the app will run much longer if not run under Instruments, to the point where I thought perhaps Instruments was the cause. But by upping the number of Image elements to 16 from 4, the app crashed in about 2 minutes when not running under instruments.
The text was updated successfully, but these errors were encountered:
Description
Any contents in a Grid will slowly leak if garbage collection is allowed to run without ever being manually called with GC.Collect().
The app will eventually crash when navigating to and away from the page with the Grid; how fast depending on how big, memory-wise, the objects in the Grid are.
Observing the native memory in XCode Instruments reveals garbage collection running and collecting most, but not all, native memory of the type(s) in the Grid, e.g. MauiImage or MauiLabel.
If GC.Collect is called manually, however, the leak does not appear to occur and the app never crashes, nor do I see the same consistent overall memory growth as I do when the garbage collector runs on its own according to its algorithm.
No managed memory leak is observed according to memory usage reported by the GC API.
Reproduction Steps
MemoryLeakTestGridLeak.zip
Expected behavior
App will continue to run indefinitely without out of memory native crash.
Actual behavior
App crashes with native out of memory error.
It will take about an hour as is. Right now the Label is the only content of the Grid.
Add the commented images back in and the app will crash much faster.
See comments in GridLeakPage.xaml:
Regression?
Unknown
Known Workarounds
Manually call GC.Collect() when navigating away from the page with the Grid.
Configuration
.NET 8 MAUI
iOS 17.5.1
ARM64
Issue does not occur on Android using .NET 8 MAUI
Other information
I discovered that the app will run much longer if not run under Instruments, to the point where I thought perhaps Instruments was the cause. But by upping the number of Image elements to 16 from 4, the app crashed in about 2 minutes when not running under instruments.
The text was updated successfully, but these errors were encountered: