After some time of running, my VO always bugs out (as in, almost all plugins dont work anymore) with an "Out of memory error". The system itself has enough free RAM so thats not the issue.

There is no backtrace nor anything, just this message.

Devs don't support plug-ins. Remove the plug-ins one by one until it stops happening.

This is an internal problem with the LUA engine, hence i reported it. It isnt specific to a plugin.

While it is possible for there to be a problem with the way the game handles some things (I found such a problem when the virtual keyboard was introduced), it is more likely that the problem is being caused by one of your plug-ins not managing it's memory usage properly. You would be better served removing them all and trying to identify the culprit, which could uncover a deeper problem as you have already claimed. However, making a blanket statement about the Lua subsystem without any supporting information is not helpful.

Yeah, like draugath said, remove all plugins, then add them back one at a time (or remove one at a time) and monitor the memory usage of the game with 'top' in unix or Task Manager on windows.

As said, it has enough free memory.

This happens when you have a big (really big!) table and try to spickle it. It also happens when you try to unspickle a big table. It only happens after some days. When loading/saving spickled/unspickled a lot of data to/from a sysnote over time, this error will appear, ie probably a memleak. Unfortunately i cant fix it as its not related to the plugin.

Sry, i forgot to mention on how to reproduce it in the OP.

PS: i only saw this on android based systems. Is there a weird memory limit for android?

I suspect I can answer your question....

Lua has an automatic garbage collection system but its not at issue here.

The problem is your phone is limited in the amount of memory available so when you use functions like spickle they allocate memory off the stack and return it when done. In your case the table has become too large and having a copy on the stack causes the over run.

You need to break the table up as best you can and only load parts of it at a time. There also seems to be a limit to the amount of data you can load or save as well.

If its a table of items perhaps you could break it alphabetically. Also try not to store information that can be looked up by using the api like stock numbers or item mass.

PS The stack memory is a subset of the main memory so it shrinks somewhat in proportion.

Your kidding me right? I have outlined the system has enough free RAM (which it could use), yet only the LUA subsystem cant allocate anymore (everything else works). Also its not an phone.

EDIT: sry if that was a bit too rough/offensive...

Is there a certain memory limit for the LUA engine on android?

Android is a pretty complex platform, from a memory standpoint. You can read a bit more about it here, but fundamentally the system application killer can become aggressive in some situations where allocations happen quickly or exceed a certain threshold, even if there's technically still enough remaining memory.

This is why we still try to keep the runtime memory-footprint of the game fairly limited, in the day and age of phones with 3GB or more of ram.

So, your issues may not actually be related to Lua at all, or any limitation of VO. This can also vary by chip-provider BSP, or by OEM/ODM manufacturer, as Android is often tweaked by the given device vendor.

I would suggest you take the advice of the people trying to help you, here, and adjust how you're trying to go about your project.

thanks. i'll hack around with android then.

There is the possibility of memory fragmentation where the memory allocator can't find a single contiguous block of memory, even though there is plenty of total memory. The Android version is 32 bit so only 4 gigs of address space is available at most, and lua does do a lot of little allocations, so maybe that's what's happening when the game is run long enough.

Now that makes much more sense. i forgot crappy android is 32bit... i'll come up with something.