GNU bug report logs - #13088
stack overflow while compiling

Previous Next

Full log

Message #8 received at 13088 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Israelsson Tampe <stefan.itampe <at> gmail.com>
To: rixed <at> happyleptic.org
Cc: 13088 <at> debbugs.gnu.org
Subject: Re: bug#13088: stack overflow while compiling
Date: Thu, 6 Dec 2012 17:01:24 +0100

[Message part 1 (text/plain, inline)]

Some findings!

1. The problems probably originates in the translation to tree-il.
2. Using something like
(define-syntax my-cond
   (syntax-rule ()
      ((_ (p x ...)    )  (if p (begin x ...)))
      ((_ (p x ...) . l)  (if p (begin x ...) (my-cond . l))))

Makes the compilation to progress further but fails at a later with,
scheme@(guile-user)> (compile program #:to 'value)
language/assembly/compile-bytecode.scm:150:39: In procedure #<procedure
2be2a20 at language/assembly/compile-bytecode.scm:150:27 (x)>:
language/assembly/compile-bytecode.scm:150:39: In procedure
bytevector-u8-set!: Value out of range: 2070

I quick look at the cond clause in boot.scm does not show any evidence that
it will blow the stack. In my view the
suspect is any code in psyntax.scm that does a tree walk of the finished
code the cond clause is a really deep tree!
because that cond clause produces a already expanded large codeblock that
psyntax has to chew on while  the my-cond
clause above produces the tree-il incrementally in smaller steps.

/Stefan


On Wed, Dec 5, 2012 at 5:31 PM, <rixed <at> happyleptic.org> wrote:

> This program tries to compile a long cond expression and fails quickly with
> a stack overflow.
>
> Of course this procedure was generated and a user is unlikely to write
> such a
> long cond, but considering the simplicity of the expression I'm surprised
> that
> the stack is so solicited.
>
> Note that I tested with guile 2.0.6 and not the fresh new 2.0.7 but I
> haven't
> noticed anything in the changelog regarding memory consumption.
>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.