Huge memory leak over time on deployed stand alone

With a Xojo stand alone running on linux the mem usage is typically very low at 2-20Mb. However, lately I have noticed some of our apps consuming huge amounts of RAM. Even a dead simple app that basically has a handle url and nothing else is climbing to over 600mb over the course of a week. This has been observed with 2019r3 and 2020r2.1.

Any Ideas? At the moment I am just restarting the apps nightly but that is not ideal.

We’ve got a bug report about this happening in the EEWeb example and I’ve been looking into it, but haven’t cracked it yet.

1 Like

This same happens with an empty project (web2.0) where some url would be called like (multiple times)

In app handleurl there is nothing to handle this nor is a webpage or session called ever. It still leaks memory this way. Meaning that it’s probably internally before App.HandleURL and not user code, since none was added.

Here is a FB case about this: <>


Thanks for looking into it @Greg_O_Lone

Greg, we will need a hot fix when this is cracked for 2019r3 please.


I’m seeing this too, but in my case it seems that something changed between 2020R1.2 and the latest release. The version built with 2020R1.2 would run for weeks and not increase RAM usage, whereas the version built with 2021 R2.1 has used 800+MB after about 24 hours.


Our biggest app is increased to 400mb after 5 hours under light usage :open_mouth: That’s running 2019r3.2

Could it be a dependency update causing this? Is this a new issue?

Any change on the leaking behavior using 2021r1 or no one checked it yet?

1 Like

I can not check because the JSONItem issue is an absolute show stopper.

1 Like


1 Like

I can not check because the JSONItem issue is an absolute show stopper.
Same here. I’ll test after 2021r1.1 if that comes along to fix json.

Naughty xojo app… this app is not being used at all. The only activity would be aws health checks.


So, maybe the HandleURL is leaking (to AWS “pings”) or just some Xojo web background task leaking all the time

I suspect the same, i’ve noticed this too and reported a case for it.
It could be that the memory is growing with the sockets and the sockets never being released or xojo could explain why there is so much memory staying in use so long?

In Web apps there is no way to set and get the MinimumAvailableSockets and MaximumAvailableSockets for the webserver at runtime making it even harder to check if this is the cause.

Xojo should be investigating such issue in all levels. logging things, dumping memory, creating debug versions of Xojo and c libs involved, etc, etc. In a week the culprit would be found and fixed. Limiting sockets is not the problem, the problem is requesting resources and not releasing them at some point.


Sure you can. There are command-line options available. See:

Please would you read “runtime”? How to change at “runtime” using command-line options?

1 Like

I did. I consider “runtime” anything after “compile time”

You can set these on the command-line just as you launch your app and in by changing or adding to the args() array.