Re: list-lpeg and capture stack overflow

[Fabio Mascarenhas <mascarenhas@...>]

I found a few stack leaks in some opcodes, and plugged them. Can you
pull from the git repository and try your example again? I also
changed the runtime capture code to move the capture values to a
worklist instead of leaving them on the stack.

--
Fabio Mascarenhas


On Thu, Jun 17, 2010 at 3:45 PM, Wesley Smith <wesley.hoke@gmail.com> wrote:
> On Thu, Jun 17, 2010 at 11:33 AM, Fabio Mascarenhas <mascarenhas@acm.org> wrote:
>> Failures do an implicit close, so opens and closes may not be 1:1. And
>> it would no cause a stack leak, anyway, as the current list is kept in
>> the registry instead of the stack.
>
> Good to know!
>
>> I think the culprits are the runtime captures. The values returned by
>> a runtime capture are kept indefinitely in the stack. If there are
>> nested runtime captures then these values end up being replicated.
>> This behavior is inherited from regular LPEG... I am trying to think
>> of a way to fix it, but it is far from trivial.
>
> I see.  This is actually a huge problem for me since everything has
> nested Cmt captures.  I need these to check specific key-value pairs
> in the tree of tables and there's no other way to do it.  What the
> reasoning behind keeping around nested Cmt captures?
>
> Also, I'm not 100% sure that this is actually the problem.  If I print
> out the stack, I see the printout below after the match function runs.
>  The first 6 values are obviously the setup before match is run.
> Slots 7-15 are generated by match, however, the only captures
> generated return a capture value of nil, so something else has to be
> going on for each node in the table to be placed on the stack like
> this.
>
>
> 1 userdata
> 2 table
>        K:: number (1.000000)
>        V: table
> 3 (-13): nil
> 4 (-12): lightuserdata (0xbfffa7d0)
> 5 table
>        K:: number (1.000000)
>        V:: string (_depth_first)
>        K:: number (2.000000)
>        V:: function (0xc48340)
>        K:: number (3.000000)
>        V:: string (B)
>        K:: number (4.000000)
>        V:: string (C)
>        K:: number (5.000000)
>        V:: string (B)
>        K:: number (6.000000)
>        V:: function (0xc48470)
>        K:: number (7.000000)
>        V:: string (_patt)
>        K:: number (8.000000)
>        V:: string (_depth_first)
>        K:: number (9.000000)
>        V:: function (0xc48550)
> 6 table
>        K:: number (1.000000)
>        V: table
>        K:: number (2.000000)
>        V: table
>        K:: number (3.000000)
>        V: table
>        K:: number (4.000000)
>        V: table
>        K:: number (5.000000)
>        V: table
>        K:: number (6.000000)
>        V: table
> 7 table
>        K:: number (1.000000)
>        V: table
>        K:: number (2.000000)
>        V: table
>        K:: string (rule)
>        V:: string (A)
> 8 table
>        K:: number (1.000000)
>        V:: string (C)
>        K:: string (token)
>        V:: string (C)
> 9 (-7): nil
> 10 table
>        K:: number (1.000000)
>        V:: string (C)
>        K:: string (token)
>        V:: string (C)
> 11 table
>        K:: number (1.000000)
>        V:: string (C)
>        K:: string (token)
>        V:: string (C)
> 12 table
>        K:: number (1.000000)
>        V: table
>        K:: number (2.000000)
>        V: table
>        K:: string (rule)
>        V:: string (A)
> 13 table
>        K:: number (1.000000)
>        V: table
>        K:: number (2.000000)
>        V: table
>        K:: string (rule)
>        V:: string (A)
> 14 table
>        K:: number (1.000000)
>        V: table
> 15 table
>        K:: number (1.000000)
>        V: table
> nil
>