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: Tue, 11 Dec 2012 23:29:31 +0100 Message-ID: References: <20121205163130.GA25037@securactive.lan> <20121210121609.GA15887@securactive.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf30434a543c920304d09b370f X-Trace: ger.gmane.org 1355265036 1467 80.91.229.3 (11 Dec 2012 22:30:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2012 22:30:36 +0000 (UTC) Cc: 13088@debbugs.gnu.org To: Chapi Chapo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Dec 11 23:30:49 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 1TiYLa-00064V-C1 for guile-bugs@m.gmane.org; Tue, 11 Dec 2012 23:30:42 +0100 Original-Received: from localhost ([::1]:54807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiYLN-0007mE-ML for guile-bugs@m.gmane.org; Tue, 11 Dec 2012 17:30:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiYLJ-0007cv-7U for bug-guile@gnu.org; Tue, 11 Dec 2012 17:30:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiYLD-0001XJ-NX for bug-guile@gnu.org; Tue, 11 Dec 2012 17:30:25 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiYLD-0001XF-Jn for bug-guile@gnu.org; Tue, 11 Dec 2012 17:30:19 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TiYLu-0008Sd-9E for bug-guile@gnu.org; Tue, 11 Dec 2012 17:31:02 -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: Tue, 11 Dec 2012 22:31:02 +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.135526501932467 (code B ref 13088); Tue, 11 Dec 2012 22:31:02 +0000 Original-Received: (at 13088) by debbugs.gnu.org; 11 Dec 2012 22:30:19 +0000 Original-Received: from localhost ([127.0.0.1]:37682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiYLD-0008Rb-3J for submit@debbugs.gnu.org; Tue, 11 Dec 2012 17:30:19 -0500 Original-Received: from mail-ie0-f172.google.com ([209.85.223.172]:54843) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiYL9-0008RS-PP for 13088@debbugs.gnu.org; Tue, 11 Dec 2012 17:30:17 -0500 Original-Received: by mail-ie0-f172.google.com with SMTP id c13so14210752ieb.3 for <13088@debbugs.gnu.org>; Tue, 11 Dec 2012 14:29:32 -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=+bxRaHIK8MQP34nyy17LXMqP3TwZFQRAJHMfQcyw78Y=; b=kEJng6hEWRty7MYwB4fOA9NW/nxsvJUTfTevBEUPzy88pKBOmDKM78wHGt9o/c7j42 6wts3v2mOE5GgRht3QuaCAV/G4bCpaHIT0nm/XyjFrkfPe0cUHz92ODE+fVYplsakmRQ sbT8lR2XZAyEn7VuZyNc+Lt2Jhb/QIwh8KXpW2EfPGfm3C8MmaggYBDAluLVy/HbWlTy PqOmW/zOUN+M4DIGcfWba5FATeVNKB7YdhHaPKO8lLDW+DrxttVksGomF0//xaBBRMp7 LTLLk09F37KtqiD6hUWfLy9OWPTtUwilgDS0JFU5pXa3FyMZgwFCYMi1Ai3m/LrRcGFJ aRTQ== Original-Received: by 10.42.22.198 with SMTP id p6mr15466339icb.17.1355264972067; Tue, 11 Dec 2012 14:29:32 -0800 (PST) Original-Received: by 10.64.89.5 with HTTP; Tue, 11 Dec 2012 14:29:31 -0800 (PST) In-Reply-To: <20121210121609.GA15887@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:6671 Archived-At: --20cf30434a543c920304d09b370f Content-Type: text/plain; charset=ISO-8859-1 Hi, I did some effort into getting this working. but first you could try to use an or-map to get what you want in stead if compiling everything into code. but it's probably faster what you are doing. Anyway in vm.c I changed the #define VM_DEFAULT_STACK_SIZE (64 * 1024) to #define VM_DEFAULT_STACK_SIZE (64 * 1024 * 64) and recompiled! Then I can compile to tree-il. Compiling all the way does not work well, But if you enter scheme@(guile-user)> (compile program #:to 'value #:opts '(#:partial-eval? #f #:cse? #f)) ;;NO OPTIMIZATION PASSES It will compile to. $7 = # In all this emphasizes what I said in earlier and I would still ask for a sane way to change the stack size for guile and document it well. Cheers! /Stefan On Mon, Dec 10, 2012 at 1:16 PM, wrote: > -[ Sat, Dec 08, 2012 at 10:44:15PM +0100, Stefan Israelsson Tampe ]---- > > 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. > > If it was not obvious already I must confess I'm ignorant about the > internals > of guile (and of any other scheme compiler), so what I will say is probably > irrelevant. but I changed the cond into the equivalent if forms, which > I believe are not macros, but the result is the same (stack overflow). > > > An alternate feature request is to have some way to tell guile the size > of > > the stack at start up. > > If though that was what '(debug-set! stack x)' was for, but this does not > seams to change anything. I also tried changing stack limits with ulimit > to no avail. > > > 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. > > Any hint on how to do that specifically for guile, beyond the above > ulimit/setrlimit? > > --20cf30434a543c920304d09b370f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I did some effort into getting this working. but fir= st you could try to use an=A0
or-map to get what you want in stea= d if compiling everything into code. but it's probably
faster= what you are doing.

Anyway in vm.c I changed the=A0
#define VM_DE= FAULT_STACK_SIZE (64 * 10= 24)

to
#define VM_DEFAULT_STACK_SIZE= (64 * 1024 * 64)

and recompiled!=A0

Then = I can compile to tree-il. Compiling all the way does not work well,
But if you enter
scheme@(guile-user)> (compile program= #:to 'value #:opts '(#:partial-eval? #f #:cse? #f)) =A0;;NO OPTIMI= ZATION PASSES

It will compile to.

$7 =3D #&l= t;procedure 3708400 (proto server-port client-zone server-zone signature-id= )>


In all this emphasizes = what I said in earlier and I would still ask for a sane way to change the s= tack size for guile
and document it well.

Cheers!
/Stef= an




On Mon, Dec 10, 2012 at 1:16 PM, <rixed@happ= yleptic.org> wrote:
-[ Sat, Dec 08, 2012 at 10:44:15PM +0100, St= efan Israelsson Tampe ]----
> The whole macro-expansion to tree-il in psyntax is n= ot done in a tail call
> manner which limits the sizes
> of code tree's that we can compile. Although it would be interesti= ng 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 imple= ment
> growing stacks.

If it was not obvious already I must confess I'm ignorant about t= he internals
of guile (and of any other scheme compiler), so what I will say is probably=
irrelevant. but I changed the cond into the equivalent if forms, which
I believe are not macros, but the result is the same (stack overflow).

> An alternate feature request is to have some way to tell guile the siz= e of
> the stack at start up.

If though that was what '(debug-set! stack x)' was for, but t= his does not
seams to change anything. I also tried changing stack limits with ulimit to no avail.

> 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.

Any hint on how to do that specifically for guile, beyond the above ulimit/setrlimit?


--20cf30434a543c920304d09b370f--