Cascading memory leak when StrokeShape is set via a global style on Border control
AdamEssenmacher opened this issue · 7 comments
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
- Create MAUI app using standard template
- Push/pop page containing a Border control
- Force GC
- Observe leak
- Push/pop page containing a Border control with StrokeShape property explicitly set
- Force GC
- 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
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.
This is probably a kind-of duplicate of this for which I already proposed a couple of solutions and a temporary workaround: #18925
@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.
Seeing the same issue on 8.0.14. Any timeline for a fix?
@AdamEssenmacher
Thanks for MemoryToolkit ;-) Helped a lot to identify issues
Appears to be fixed in 8.0.40-nightly.10455
Thanks! Fix was:
@jonathanpeppers please also look at my comment here:
#18925 (comment)
Number 1 is still an issue even if the leak has been fixed.