From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.bugs Subject: bug#13088: stack overflow while compiling Date: Thu, 6 Dec 2012 17:01:24 +0100 Message-ID: References: <20121205163130.GA25037@securactive.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc1a3a00b50c04d0313619 X-Trace: ger.gmane.org 1354809730 17312 80.91.229.3 (6 Dec 2012 16:02:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2012 16:02:10 +0000 (UTC) Cc: 13088@debbugs.gnu.org To: rixed@happyleptic.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Dec 06 17:02:23 2012 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tgdu0-0000qW-46 for guile-bugs@m.gmane.org; Thu, 06 Dec 2012 17:02:20 +0100 Original-Received: from localhost ([::1]:60991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgdto-0006xt-3a for guile-bugs@m.gmane.org; Thu, 06 Dec 2012 11:02:08 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tgdtg-0006xW-J9 for bug-guile@gnu.org; Thu, 06 Dec 2012 11:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgdtU-00031V-O3 for bug-guile@gnu.org; Thu, 06 Dec 2012 11:02:00 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgdtU-00031P-K3 for bug-guile@gnu.org; Thu, 06 Dec 2012 11:01:48 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tgdth-0002JH-Tp for bug-guile@gnu.org; Thu, 06 Dec 2012 11:02:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Israelsson Tampe Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 06 Dec 2012 16:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13088 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 13088-submit@debbugs.gnu.org id=B13088.13548097048854 (code B ref 13088); Thu, 06 Dec 2012 16:02:01 +0000 Original-Received: (at 13088) by debbugs.gnu.org; 6 Dec 2012 16:01:44 +0000 Original-Received: from localhost ([127.0.0.1]:56992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgdtP-0002Il-Ru for submit@debbugs.gnu.org; Thu, 06 Dec 2012 11:01:44 -0500 Original-Received: from mail-qa0-f44.google.com ([209.85.216.44]:35504) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgdtM-0002Ia-Vj for 13088@debbugs.gnu.org; Thu, 06 Dec 2012 11:01:42 -0500 Original-Received: by mail-qa0-f44.google.com with SMTP id z4so899455qan.3 for <13088@debbugs.gnu.org>; Thu, 06 Dec 2012 08:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J9smTwlh/2RUByxg93QIDFnz8F41hC34WPl4xZchfg8=; b=rTCdOjrTLB7do4pSLqak7SdephNiBHhDG0S/bswKUzxH2BoS2NOmoByPumH18isWNd 3P/oIjn+WOzX5zRvUOcayMxLrPlkYUSqMpXILjQq7+9ghiUdPwtW+06YCMOu/UWhXvvj 0p7Sei47GkCqgvOcudABpg2Pwlbeevm/ZyiU4SM+Wj8hId0PEtXZMY9+rde27CS7TVDD lwjI6vQoM5nU0C/7f6Hq+E3xzFj5iXdd9mp2boqryJfVBEA1oybroZ0SobrOGThQQZfO NQUW3ir3NNTIzDumbkgVy4wdAcMM8BM2zBAbrbcEedAgEDgwYuNThr5mcseUoseIIweg WYGg== Original-Received: by 10.49.63.104 with SMTP id f8mr3800097qes.29.1354809684833; Thu, 06 Dec 2012 08:01:24 -0800 (PST) Original-Received: by 10.49.28.135 with HTTP; Thu, 6 Dec 2012 08:01:24 -0800 (PST) In-Reply-To: <20121205163130.GA25037@securactive.lan> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6646 Archived-At: --047d7bdc1a3a00b50c04d0313619 Content-Type: text/plain; charset=ISO-8859-1 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 #: 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, 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. > > --047d7bdc1a3a00b50c04d0313619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some findings!

1. The problems probably originates in the translatio= n to tree-il.
2. Using something like
(define-syntax my-cond
=A0= =A0 (syntax-rule ()
=A0=A0=A0=A0=A0 ((_ (p x ...)=A0=A0=A0 )=A0 (if p (b= egin x ...)))
=A0=A0=A0=A0=A0 ((_ (p x ...) . l)=A0 (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/asse= mbly/compile-bytecode.scm:150:39: In procedure #<procedure 2be2a20 at la= nguage/assembly/compile-bytecode.scm:150:27 (x)>:
language/assembly/compile-bytecode.scm:150:39: In procedure bytevector-u8-s= et!: Value out of range: 2070

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

/S= tefan


On Wed, Dec 5= , 2012 at 5:31 PM, <rixed@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 surpris= ed 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.


--047d7bdc1a3a00b50c04d0313619--