I am still developing my app using the old IDE, i.e. Real Studio 2012r2.1. That’s why I’ve not noticed until now that all Xojo versions (tested with 2013r3.3 and 2016r4.1) cause a huge memory leak that does not occur with the 2012 version. Eventually, this leads to my app freezing and crashing, when all of the 4 GB of VM are used up. And while I never run into this myself because I keep restarting the app all the time, I had received quite a few crash reports from users that I hadn’t realized were all due to this problem, until now. It’s currently the most-reported crash cause of iClip (the next one is 3 times less often). This is worrying me.
So, now I wonder: How can it be that there’s a memory leak that’s been introduced about 4 years ago and hasn’t been tackled, yet?
It could be that I’m doing something odd, or it could be a yet-unknown leak, or it’s a known leak that hasn’t been addressed yet.
While I’m now looking into finding what exactly causes this leak (which is a major effort due to the complexity of iClip’s drawing code), I wonder if others know of such leak issues, especially around Canvas (no ContainerControls involved), possibly also involving MBS (though the very same MBS plugins do not cause this leakage with RS 2012!), and that have been introduced shortly after RS 2012r2.1 and that still exist.
Nope, I don’t see a huge memory leak in the apps I make with Xojo. The only big memory leak I get is in Xojo itself. Which crashes after a couple of dozen debug builds, but I seem the only one to get such a crash.
After some testing I fear the issue is worse than I thought:
It appears that there’s no actual leak, i.e. there’s no user object allocated that isn’t getting freed. For instance, Runtime.ObjectCount remains stable (it does not go up constantly), and Runtime.MemoryUsed keeps orbiting around a fairly stable value as well.
Yet, both the app’s “Real memory” and the “Virtual memory” keep going up. Every time I open a Window, they increase by around 2 MB. Even if I strip the window down to its bare minumum, it still consumes about 150 to 200 KB every time.
Instruments tells me that this goes along with new 64 KB memory blocks being constantly allocated, and not being freed.
All this suggests that this is caused by a fundamental flow in Xojo’s own memory management: I suspect Xojo’s runtime manages its own memory pools, instead of using the ones provided by the framework, and due to memory fragmentation caused by the many different allocations my app performs between opening and closing the same window, this leads to the effect that Xojo’s runtime keeps allocating new 64 KB blocks, until the entire memory space is used up and the app crashes.
And the fact that this does not happen with RS 2012r2 suggests that either that version did not use its own Xojo-private pools yet or that the layout was different in a way that prevented such memory exhaustion within my app.
So, what now?
Can someone from Xojo clarify this? Was there indeed a change to the memory management done between 2012r2 and 2013r3? Does it currently use its own pools? Is there a way to stop this (even at the cost of performance, which was probably the reason for using its own pools in the first place)?
This effect I supect to happen here might also be the cause of the Xojo IDE crashing eventually, BTW. Especially if the devs at Xojo are sure there is no such leak because their own Runtime memory checks tell them that they’re not leaking.
Also, to clarify: The “Real memory” used by my app use only about a few 100 MBs. But due to the severe fragmentation, it ends up spreading over the entire 4 GB address space, at which point the app crashes. So, it’s not that my app actually uses too much memory, it’s rather that it has no control over the fragmentation that’s happening over time. Ideally, though, since my app keeps simply allocating and freeing the same amount of memory, this fragmentation should not happen. The fact that it does shows a weakness in Xojo’s memory management. I like to be proven wrong that this is a case, of course, so that I can work around this issue, but all I found out so far indicates the contrary.
I have never seen such a memory link in Xojo built apps. It could be from something in your app. Given what you describe, I would not be surprised if some declare was the culprit.
Right, Michel, because declares only work in 2013 and above, and are ignored in 2012 versions of Xojo. In other words: You’re not helping. (and yes, I’ve made sure that it’s not some code that’s getting conditionally compiled in based on the RBVersion constant)
Hum. What do you mean ? RS 2012 R2.1 did not support declares ? That’s new.
Sorry if I did not help. Shooting in the dark. Without no more than a description, it would be difficult to pinpoint the reason for crash where there is apparently not even any log. Powerful thread title, though…
I thought that window leak had been fixed, but evidently not. Are you only losing memory when a window is opened and closed?
I had a problem recently involving threads where the auto-release pool created for the thread by Xojo was not released until the thread was destroyed, and since I was keeping that thread for background processing for the entire runtime of the program anything that would have been released never was. I solved the by managing my own auto-release pools. I THINK that has been fixed since then as in some version after that I started getting errors about incorrectly releasing the pools and I realized that they had not documented the fact that they started regularly releasing the memory again. I havent tested that lately or worked on that application in the last couple of versions so I dont know if the problem also regressed back in like the window one. But if youre using threads there is definitely a possibility of it not releasing that threads pools unless you do it specifically.
Then there are some situations where Im working with Core Image and it just leaks down in Apples code as far as I can tell. I had to move some core image processing out to a separate process entirely and launch it as a helper with shared memory to the main app to get around that. Every so often I have to quit and restart the helper app to release its memory.
Apart from that though I definitely can release an app that will run for months without using up its VM allocation, so its not just the act of living that is leaking, its got to be narrowable down to something.
If Xojo had been leaking as severely for 3 years as reported in the OP, it would be extremely obvious by now.
How many hundreds if not thousands of apps are created in Xojo ? If it was leaking any time canvases are used, the IDE itself would be like a fountain.
There must be something specific to the app described above that creates the condition of the leak/crash.
If it’s the issue Norman mentioned it probably wouldn’t be an issue in my apps because it doesn’t open and close windows. I make heavy use of PagePanel. I am curious to know whether it would impact the container controls as I’ve started using those more often and from what I understand they are some kind of window derivative.
The bug reported is about 1Mb per window. Admitting the same manifests with ContainerControls (not aware of that, it is not a given), it would take 3000 windows/CC to fill 3 Gb. Thomas talks about the app filling 4Gb…
If the leak is create at each time one close and open a window, why don’t you create a simple application that open / close a window, say 1,000, 10,000, 1,000,000 times ?
Seriously, if it is so easy to demonstrate the bug I am quite sure that TT already tested that.
It makes use of the clipboard extensively, and displays pictures of the items collected.
Are they rendered based on copies held in memory? Full images held in memory can easily eat up the 4Gb.
Or are they thumbnails that represent a temp file stored on disc by iClip?
Maybe the machines run out of disc space?
The window memory leak on macOS is even bigger for Retina: <https://xojo.com/issue/34956>
(<https://xojo.com/issue/45697> in which I describe it is unreviewed and was issued during a beta phase, thats why its limited to Alpha/Beta testers)
