> The GC doen't use any kind of explicit recursion nor large stack
> buffers. It is written assuming a restricted stack. But some obscure
> behavior may create recursive calls. Is it possible for your allocator
>to fail when shrinking a memory block?
I just run some tests on this, and it seems that there is no problem with reallocating smaller blocks.
> Any memory-allocation fail may trigger an "emergency collection".
> During a GC cycle (finalizers are out of this story), Lua never
> allocates new memory, but it may shrink some structures. If
> shrinking fails (what Lua assumes should not happen), the emergency
> collection will start a new collection, which will fail again,
> creating a recursive loop.
Could this condition be triggered due to heap fragmentation?
For example:
1. Lua runs out of memory.
2. Emergency GC is executed, some memory is actually freed. Heap is severely fragmented.
3. Lua tries to store some data, which normally should fit into the heap (due to previous GC). Due to high fragmentation allocation fails.
4. Lua calls emergency GC.
5. Repeat...
> Is it possible to have at least some estimate for the number of function
> calls in the stack?
I have no idea what is the stack trace at the moment of the error, but here is the sequence of functions I call.
- There are four nested C functions, stack usage is minimal.
- The fifth level of nesting is lua_pcall(). (No idea what happens next in terms of function calls)
- The called Lua function is the provided example above, no other function calls in Lua.
I am pretty confident that the issue is caused by the GC. I measure the stack exactly before and after lua_pcall(),
and indeed this is where the stack is used. I also placed some prints and I see that stack usage increases only when
GC is running.
Note that stack is used progressively. On every GC call, more and more is requested till the exhaustion. On the first
calls the usage is pretty minimal.
