Cascading memory leak when StrokeShape is set via a global style on Border control

[AdamEssenmacher]

Description

Setting the StrokeShape property on a Border control via a global style results in the control and its containing page to leak.

Page-level leaks are serious, as they prevent child elements from being collected as well.

It's also noteworthy that the OOTB MAUI template creates a global Border style with the StrokeShape set, so all MAUI apps created with the standard solution template will have this page-level cascading leak unless the global style is removed or StrokeShape is explicitly set.

I recommend the area/perf label for the issue.

Also, I'm guessing this applies to iOS as well as Android. However, iOS currently leaks no matter how the StrokeShape property is set, so it can't be properly tested.

Steps to Reproduce

1. Create MAUI app using standard template
2. Push/pop page containing a Border control
3. Force GC
4. Observe leak
5. Push/pop page containing a Border control with StrokeShape property explicitly set
6. Force GC
7. Observe no leak

Link to public reproduction project repository

https://github.com/AdamEssenmacher/BorderStyleLeak.Maui

Version with bug

8.0.3

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[albyrock87]

This is probably a kind-of duplicate of this for which I already proposed a couple of solutions and a temporary workaround: #18925

[AdamEssenmacher]

@albyrock87 I think they're related but our complaints are distinct. Your issue is focused on loading performance, while this one is specifically focused on garbage collection / memory leakage.

Both issues have a common cause in a global shared reference, and might have a shared fix.

[Larhei]

Seeing the same issue on 8.0.14. Any timeline for a fix?

@AdamEssenmacher
Thanks for MemoryToolkit ;-) Helped a lot to identify issues

[AdamEssenmacher]

Appears to be fixed in 8.0.40-nightly.10455

[jonathanpeppers]

Thanks! Fix was:

• [ios] fix memory leak in RadioButton #21151

[albyrock87]

@jonathanpeppers please also look at my comment here:
#18925 (comment)

Number 1 is still an issue even if the leak has been fixed.