I have been battling many different memory leaks on this project of mine that all seem to reside in the Xojo Framework like the label color and async shell leaks. I think I have found another with container controls on Raspberry Pi.
In my app, I create and destroy ContainerControls with code like this:
// CustomContainer is a property of type CustomContainerControl
// CustomContainerControl has one label in it
// Create Container
CustomContainer = New CustomContainerControl
CustomContainer.EmbedWithin(Self,0,0,Width,Height)
// Destroy Container
CustomContainer.Close
CustomContainer = Nil
On macOS there is no problem, it appears to create and destroy the container without leaking, however, on Raspberry Pi it leaks about 47KB each time the control is created and destroyed. In my app I use container controls for everything, all the navigation is based on changing the displayed container, I have nested containers that are created at design time and containers that are created runtime. With my full app I can leak the entire system memory (4GB) in a very short time.
Can someone with a Linux desktop machine please confirm this affects all Linux OS’s or just Raspberry Pi?
I have a feeling that it will be a while till we see a future release of Xojo so I’m a bit lost at the moment…
There also seems to be a leak when showing and closing windows on all platforms, especially linux. Showing and closing windows with container controls leaks just the same.
Hmm, I guess I should have tested it in a newer version… This appears to have been fixed (at least on Raspberry Pi) somewhere between 2019r2.1 and 2019r3.1, however, I cannot seem to find it mentioned in the release notes and no feedback case exists.
I am unable to use 2019r3.1 as the navigator is just too slow, once again I am stuck between a rock and a hard place. I can’t use container controls unless I upgrade but if I do I won’t be able to write any code.
Begging the devs for a 2019r3.3 with some more fixes while we wait for 2020r1.
Here is my sample project, please confirm this affects other platforms.
i made some more tests with windows
r3.1
if other cc Embed in cc with .EmbedWithin they need to close manually before the parent is close
i think this should happen automatically.
It is fixed in pre-releases (thanks a million ) just have to wait till it’s released to use it and container controls. It’s like the saying, “do you want it done fast, cheap or good, pick 2” but rather “do you want container controls, navigator, or both but in a pre-release”
@MarkusR if other cc Embed in cc with .EmbedWithin they need to close manually before the parent is close
i think this should happen automatically.
@Greg_Ođ–˝‘Lone does calling ContainerControl.Close not kill all child controls? Do we need to call close on each control from the Closing event handler? How about if we embedded a cc and set it to a property, will that get destroyed properly? I would think it would be closed when the parent is closed, as long as their are no more references to the property it should also be destroyed when the parent is destroyed.
) just have to wait till it’s released to use it and container controls. It’s like the saying, “do you want it done fast, cheap or good, pick 2” but rather “do you want container controls, navigator, or both but in a pre-release”