Open wtholliday opened 13 years ago
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?
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.
Does your table by chance have circular references?
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?
Curiosity, mainly. I'm wondering if there's a bug storing circular references.
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.