Severe memory leakage since Xojo 2013 related to frequently opening windows

It probably means the larger the window the larger the leak as well. Ouch.

I could not verify that, but I haven’t tested that intensively.

So the forced release in the close event doesn’t work to solve this anymore? Yikes… I need to investigate that.

I just entered a sample project to show problem and I can reproduce it:

<https://xojo.com/issue/46549>

On the Mac, Open Activity Monitor, select your app’s process and click the (i) button. Then watch the “Real memory” and “virtual memory” sizes. If they constantly go up, you’re likely to have a leak.

I have attached another test project to Christian’s report (<https://xojo.com/issue/46549>) that demonstrates the issue more clearly. It opens and closes a window frequently, using a Timer, while showing the app’s used memory. That goes up by about one MB per second, and will crash eventually due to all VM used up. That’s the bug I was talking about.

So, my suspicion about a bad memory allocation scheme does not seem to be the cause, which is a relief. It’s just a simple leak, after all.

In fact, the bug report Norman pointed out seems to be the same, so Christian’s can be merged with <https://xojo.com/issue/43484>.

And the release call inside CancelClose seems still to work - at least in my test, it does. Mostly.

I still see a smaller leak with the work-around, but it’s much better than currently. I still hope the leaks are all fixed sooner than later. I can’t have my app (which runs all the time in the background, i.e. never gets quit, ideally) crash after a few days or weeks of running because it’s running out of memory due to such leaks.

There is also the following Feedback Case that doesn’t benefit by the workaround of Feedback Case #43484.
Feedback Case #42044 - Closing a window containing pagepanel does not release memory usage

Well, there are probably 10 cases related.

And it’s important to have each with a sample project.
Now Xojo engineers can fix the NSWindow leak and than run all those test projects and see if things get better.
And than mark all those cases as fixed or not.

Because there may be other leaks!
The page panel one could be the same NSWindow leak or a different one!

I am still curious why the Virtual Memory raises so quickly to 4 GB due to this leak even though the Real Memory usage stays around 1 GB.

That still suggests a memory fragmentation issue, so I still like to get an answer on my original suspicion that Xojo has its own memory pool.

If that’s the case, then this suggests that it’s not using and freeing those pools properly. By that I mean that there are common optimizations for memory pools, and one is to re-use the last freed block. That method would be wrong in this case because that will lead to the fragmentation I’m seeing! Instead, a second-level pool (like I suspect Xojo is using) needs to try to prefer the older pools for re-allocation so that younger pools can be kept as empty as possible, and returned to the system pool ASAP when they’re empty again. This will make allocations a bit slower but will prevent the fragmentation issue I am seeing. And it would be only necessary to do this in 32 bit apps. In 64 bit apps, the VM space is large enough so that fragmentation won’t be an issue as long as the pool sizes are aligned with VM page sizes.

Can someone from Xojo with some insight in the memory management comment on this, please? (Am I even being understood or am I not making sense? I can elaborate this with examples if it helps. But getting no answer at all only indicates that either there’s no time to even look at this - which would be worrysome - or that no one thinks I have a valid point, which would be even worse.)

@Christian Schmitz [quote]The page panel one could be the same NSWindow leak or a different one![/quote]
I recall Joe saying that the page panel leak is probably different than NSWindow leak. That’s why I opened a new case for it.

Do you use IPCSockets? I found a bad leak <https://xojo.com/issue/34107>

[quote=308748:@Christian Schmitz]I just entered a sample project to show problem and I can reproduce it:

<https://xojo.com/issue/46549>[/quote]

Only ranked 169th in the Feedback app. This seems really problematic for some apps. Lets shine some light on it.

Thomas,

this may (is certainly not) related to your finding, but Firefox leaks 20MB by downloaded file (checked with theActivity Monitor) when I download more than 1 file at a time. This explain a bit why after some hours I get Firefox working from slow to slower. It does not explain everything, but this is a huge discovery. Quit and Fire set the memory footprint back to default, but the leak restart as soon as I download more than a file at a time.

This may also explain why I have troubles when Xojo runs and Firefox too. (I am not sure of the cause, but I get the effects)

on Sierra, i don’t see Virtual Memory in the list of value after doing a right click.