pluto runs out of stack easily

[wtholliday]

Pluto is recursive and runs out of either C stack or Lua C API stack. The following code will cause a Lua C API stack overflow.

t = {}
for i=0,8000 do
  t = { t }
end

buf = pluto.persist({}, t)

[hoelzro]

On my machine (64-bit Arch Linux, 4GB RAM), Pluto can go 6518 levels deep before segfaulting (based on a script I wrote based on your code above). I tested this on a 32-bit virtual machine (Arch Linux, 128MB RAM) as well, and it went 6648 levels deep before it segfaulted. I feel like that's sufficiently deep for most applications (at least I don't believe it merits completely restructuring Pluto's internals); do you have a use case where stack levels this deep are neccessary?

[wtholliday]

Hi, yes I ran into this while trying to persist a data structure which is essentially a state transition diagram (a directed graph). Its not a particularly large data structure. My work-around is to write a __persist function for it that saves the graph using indices instead of table references, to avoid the recursion.

Note that Pluto is currently ignoring the result of lua_checkstack in various places, so the segfaults resulting from Lua API stack overflow can be avoided without much work (I modified mine to do so). However, I don't know how to portably catch C stack overflow.

I agree with you that it would require restructuring pluto.c to properly handle nested data structures and that might be a lot of work. So it might be better to just try to error out without segfaulting.

[hoelzro]

Does your table by chance have circular references?

[wtholliday]

The data structure itself does not. In fact, its actually just a tree. However, in my case, data can be embedded in the tree that could ultimately point back to another node in the tree, creating a referential cycle. Why do you ask?

[hoelzro]

Curiosity, mainly. I'm wondering if there's a bug storing circular references.