Re: [Chicken-users] jbogenturfa'i: "Error: stack overflow"

[Alan Post]

On Sat, Dec 04, 2010 at 03:04:56PM +0100, Felix wrote:
> From: Alan Post <address@hidden>
> Subject: [Chicken-users] jbogenturfa'i: "Error: stack overflow"
> Date: Fri, 3 Dec 2010 16:39:42 -0700
> 
> > 
> > May I have some guidance on what is happening here?  Am I on the
> > right track by adjusting my stack size?  How do I learn how much 
> > I need?  Is it reasonably to try this on another operating system
> > on the chance that I need more than 32MB of stack?  What else should
> > I try?
> 
> Don't bother with fiddling with the stack size, the problem here
> is possibly some sort of runaway recursion. The "stack" used in compiled
> code is just a special kind of heap. Do you get some sort of backtrace?
> Can you pin down the location?
> 
> 
> cheers,
> felix

I increased by debug level to '-d2' and I do at that point get a
stack trace:


  $ ./jbogenturfahi                      

  Error: stack overflow

        Call history:

        jbogerna.scm:420: genturfahi#morji-nunjavni-!     
        jbogerna.scm:420: genturfahi#morji-nunjavni-je    
        jbogerna.scm:416: genturfahi#morji-nunjavni-jonai         
        jbogerna.scm:415: genturfahi#morji-nunjavni-*     
        jbogerna.scm:423: genturfahi#morji-nunjavni-&     
        jbogerna.scm:413: genturfahi#morji-nunjavni-je    
        jbogerna.scm:412: genturfahi#nunjavni-morji       
        jbogerna.scm:427: genturfahi#morji-nunjavni-&     
        jbogerna.scm:428: genturfahi#morji-nunjavni-jonai         
        jbogerna.scm:428: genturfahi#morji-nunjavni-*           <--

What this tells me is that it is the process of initializing the
parser that I'm getting a stack overflow.  When I add a print
statement between each rule definition, I pinpoint the rule that is
causing my problem.  It happens while I am trying to construct the
rule for 'jbocme'.  That is pretty early in the parser generator.

I didn't find, as I looked at this last night, how I could be
getting runaway recursion, but I believe you're correct.  I suspect
my memoizer or this point, but playing with it last night didn't
produce any change in result.

Is there a way to increase the length of the call history?  I looked
for it by grepping around chicken core, but I couldn't find it.  I'd
like to see a much larger call history, as if I do have runaway
recursion, I think it is happpening over a >10 length call sequence.

I don't understand *how* this could could yet have runaway
recursion, as each rule generator should construct a rule and pass it
to the next in sequence, but none of the individual rule generators is
recursive, they construct their rule (which itself will sometimes
recurse over their input, but aren't being run yet.)  The recursion
depth should therefor be visible in the compiler output based on how
many rules are used in a single production.

If I were going to see runaway recursion, I would expect to see it
during a parse.  Which is all a long way of saying that it's not
quite clear to me yet what is going on.

Time to play with the trace egg?

-Alan
-- 
.i ko djuno fi le do sevzi