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: Sat, 8 Dec 2012 22:44:15 +0100 Message-ID: References: <20121205163130.GA25037@securactive.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf3074b1fec73aa804d05e3bb3 X-Trace: ger.gmane.org 1355003081 15338 80.91.229.3 (8 Dec 2012 21:44:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Dec 2012 21:44:41 +0000 (UTC) Cc: 13088@debbugs.gnu.org To: Chapi Chapo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Dec 08 22:44:54 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 1ThSCb-0002Hc-7a for guile-bugs@m.gmane.org; Sat, 08 Dec 2012 22:44:53 +0100 Original-Received: from localhost ([::1]:56062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThSCP-0004yC-16 for guile-bugs@m.gmane.org; Sat, 08 Dec 2012 16:44:41 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThSCL-0004y6-N5 for bug-guile@gnu.org; Sat, 08 Dec 2012 16:44:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ThSCK-0001nX-5M for bug-guile@gnu.org; Sat, 08 Dec 2012 16:44:37 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThSCK-0001nS-1o for bug-guile@gnu.org; Sat, 08 Dec 2012 16:44:36 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1ThSCj-0003I7-UE for bug-guile@gnu.org; Sat, 08 Dec 2012 16:45: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: Sat, 08 Dec 2012 21:45: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.135500308712616 (code B ref 13088); Sat, 08 Dec 2012 21:45:01 +0000 Original-Received: (at 13088) by debbugs.gnu.org; 8 Dec 2012 21:44:47 +0000 Original-Received: from localhost ([127.0.0.1]:33259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ThSCU-0003HR-DB for submit@debbugs.gnu.org; Sat, 08 Dec 2012 16:44:46 -0500 Original-Received: from mail-qa0-f44.google.com ([209.85.216.44]:43260) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ThSCQ-0003HE-02 for 13088@debbugs.gnu.org; Sat, 08 Dec 2012 16:44:43 -0500 Original-Received: by mail-qa0-f44.google.com with SMTP id z4so633967qan.3 for <13088@debbugs.gnu.org>; Sat, 08 Dec 2012 13:44:15 -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=keR6BEd+R0d47tzSNfXlajrMfXlNircTnnjlaCy2Mos=; b=Q+DPWozphbfYnVhZVA9bF2kkmZ4HJJRVTN2MFBkggWTHKbfSmrv8Y2D3jnPhCC15Eg HTrGRh3Www2oCmFoVpnehYzv8s/7djVo6Wo6RP0Gl9j6B9Asia7OxWGJa2ZLSsbtAhAl Q3YWPTvvue2Ra/fM8/hB8hF8mVG+ZdXDAImxOrpfJcY2LZq/auCjyFsFx0+XHUAMt4h5 d0mmzvBEu+Vcijx2fj3bRA9SwVpnRPX8Leixk6n2f2f+Il9NN9i/lKmZY3L+XhUFni2r hD9yl3BXgrooxjMEL/H5RS+V2pAdibPwoQ0IDlA2uj7W+F0xzuXN30DAXajgXTLl4WuB IvBg== Original-Received: by 10.224.107.3 with SMTP id z3mr17961982qao.9.1355003055258; Sat, 08 Dec 2012 13:44:15 -0800 (PST) Original-Received: by 10.49.28.135 with HTTP; Sat, 8 Dec 2012 13:44:15 -0800 (PST) In-Reply-To: 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:6661 Archived-At: --20cf3074b1fec73aa804d05e3bb3 Content-Type: text/plain; charset=ISO-8859-1 Some further findings, The whole macro-expansion to tree-il in psyntax is not done in a tail call manner which limits the sizes of code tree's that we can compile. Although it would be interesting to know how to code the psyntax expand algorithm in such a way that we don't risk blowing the stack, I think we will be better served by waiting for better stack algorithm that implement growing stacks. For the second bug above, it's not a bug, it's my-cond syntax not being recognized and it tries to tail-call 2000+ argument function which is not supported in guile :-) In view of this I suggest that we close this bug or perhaps add a feature request for growing stacks. An alternate feature request is to have some way to tell guile the size of the stack at start up. For now anyone that need to compile large functions the only option, I believe, is to change the stack size in the code and recompile. WDYT /Stefan On Thu, Dec 6, 2012 at 5:01 PM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > 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 # 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, 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. >> >> > --20cf3074b1fec73aa804d05e3bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some further findings,

The whole macro-expansion to tree-il in psynt= ax is not done in a tail call manner which limits the sizes
of code tree= 's that we can compile. Although it would be interesting to know how to= code the
psyntax expand algorithm in such a way that we don't risk blowing the s= tack, I think we
will be better served by waiting for better stack algor= ithm that implement growing stacks.

For the second bug above, it'= ;s not a bug, it's my-cond syntax not being recognized and it tries
to tail-call 2000+ argument function which is not supported in guile :-)
In view of this I suggest that we close this bug or perhaps add a feat= ure request for growing stacks.
An alternate feature request is to have = some way to tell guile the size of the stack at start up.

For now anyone that need to compile large functions the only option, I = believe, is to change the stack size in the code
and recompile.

W= DYT
/Stefan

On Thu, Dec 6, 2012 at 5:01 PM, Stefan Israelsson Tampe &= lt;stefan.itam= pe@gmail.com> wrote:
Some findings!

1. The problems probab= ly originates in the translation 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 (begin 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.

/Stefan



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.



--20cf3074b1fec73aa804d05e3bb3--