ContainerControl Memory Leak on Linux (Raspberry Pi)

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…

Any ideas would be helpful, thanks!

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.

1 Like

i tested a Windows with 2019r3.1
yes the ObjectCount go up and down but MemoryUsed only up …

i need cc in a window and cc in other cc as list.

Looks like it only stays the same on macOS, maybe we can change the topic back to general?

I will make a feedback case and post it here shortly.

2 Likes

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. :pray: :heart:

Here is my sample project, please confirm this affects other platforms.

1 Like

Could you test with the prerelease and see if the Navigator is any better for you? If not, could you make a movie so we can see the problem?

r3.1 at windows seems no issue, the memory change a little bit after start and later it look more constant.

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 :heart:) 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.

Thanks for looking into this!

It does, assuming you are not also holding onto a reference of the container. Make sure that none of the child controls are either!

1 Like

i got the issue if inner cc are closed by automatic
it is AddHandler it need a call to RemoveHandler or all the objects stays.

1 Like