I've investigated this memory consumption issue a bit and found a bug in Octane.
All images (render results, static images or bitmap images created in Lua) are cleaned up by the garbage collector (GC). The problem is that in rendering the animation the GC isn't started. The behaviour of the Lua GC is influenced by a parameter called pause (there's also the step but that one is irrelevant here). In Octane the default value for pause is 200 which means that Lua starts collecting garbage when the memory usage doubled. But it takes a lot of frames to double the memory and that's because of how the image buffers work. Image buffers are implemented a bit special. All the memory is allocated on the C (Octane) side while Lua only has a reference to this buffer which is a few bytes. The consequence is that the Lua interpreter thinks that we're only allocating a little bit memory (not worth starting a GC cycle) while on the Octane side we are allocating big chunks that the interpreter isnt aware of. Eventually the GC will start but by then the system might be OOM.
This will be fixed in the next release by monitoring the memory usage of the image buffers separately and kicking the GC when it goes out of control. Unfortunately our solution is only a heuristic but it's the best we can do and it seems to work fine on my machine.
@jason: using
print(collectgarbage("count"))
is an underestimation of the memory the script is using. Right now there's no reliable way of figuring out how much memory the script is consuming.As a work around you can call
collectgarbage
in the script like gmillas did or you can tune the GC parameters more aggressively at the beginning of the script.Thanks for your help figuring this out!
cheers,
Thomas