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: Wed, 12 Dec 2012 18:13:39 +0100 Message-ID: References: <20121205163130.GA25037@securactive.lan> <20121210121609.GA15887@securactive.lan> <20121212083335.GA2565@securactive.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=047d7bdc1be47483ba04d0aaeba2 X-Trace: ger.gmane.org 1355332479 29123 80.91.229.3 (12 Dec 2012 17:14:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Dec 2012 17:14:39 +0000 (UTC) Cc: 13088@debbugs.gnu.org To: Chapi Chapo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Dec 12 18:14:51 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 1TiptK-0003G0-NS for guile-bugs@m.gmane.org; Wed, 12 Dec 2012 18:14:42 +0100 Original-Received: from localhost ([::1]:49807 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tipt7-0005Xv-UW for guile-bugs@m.gmane.org; Wed, 12 Dec 2012 12:14:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tipsz-0005WI-Cb for bug-guile@gnu.org; Wed, 12 Dec 2012 12:14:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tipst-0001u6-Bq for bug-guile@gnu.org; Wed, 12 Dec 2012 12:14:21 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tipst-0001tx-7s for bug-guile@gnu.org; Wed, 12 Dec 2012 12:14:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tipte-0007LQ-4S for bug-guile@gnu.org; Wed, 12 Dec 2012 12:15: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: Wed, 12 Dec 2012 17:15: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.135533247228164 (code B ref 13088); Wed, 12 Dec 2012 17:15:02 +0000 Original-Received: (at 13088) by debbugs.gnu.org; 12 Dec 2012 17:14:32 +0000 Original-Received: from localhost ([127.0.0.1]:39300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiptA-0007KC-10 for submit@debbugs.gnu.org; Wed, 12 Dec 2012 12:14:32 -0500 Original-Received: from mail-qa0-f51.google.com ([209.85.216.51]:49381) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tipt7-0007K4-6p for 13088@debbugs.gnu.org; Wed, 12 Dec 2012 12:14:30 -0500 Original-Received: by mail-qa0-f51.google.com with SMTP id i20so1330217qad.3 for <13088@debbugs.gnu.org>; Wed, 12 Dec 2012 09:13:40 -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=i9hKuncHHtiFVzDj6ygZkkakG4sWQ3DeZgVZI5MdAgw=; b=iGqN64xnddCObOAmeUdxIVWBxsmNqCMc8gCA/3O5j9oM289QK2HIpwcbKH56kBKD4l wFGbCiUkDn3VLDZWr7thrVl+UFemqvROy8bVl/NihRMYB4Ec6xJvXE+tyomtBTMsVchv ruWCkQRM+cmKu1zKqQ9YQNEU0ubc4xlXCxl8OrhS4jk740qUHJs9t7SsuNtSALETmdAw fxOScmLPTnvdJuRrk5GWIJWhFLXIY0zl1AVIS7spC7qPeGOeHo/7sY2jwdZjL90rkh5V DGvGkxUbSBoYkbtjV01xLCSytZA5ORodmu46LXtQw41qzEKhe7rCIvIVAQJzkQXKE2s5 2JRA== Original-Received: by 10.49.121.40 with SMTP id lh8mr4290846qeb.30.1355332420141; Wed, 12 Dec 2012 09:13:40 -0800 (PST) Original-Received: by 10.49.28.135 with HTTP; Wed, 12 Dec 2012 09:13:39 -0800 (PST) In-Reply-To: <20121212083335.GA2565@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:6674 Archived-At: --047d7bdc1be47483ba04d0aaeba2 Content-Type: multipart/alternative; boundary=047d7bdc1be47483b504d0aaeba0 --047d7bdc1be47483b504d0aaeba0 Content-Type: text/plain; charset=ISO-8859-1 Hi, I added a patch to suggest a new environment variable. GUILE_STACK_SIZE_NSCM If this is defined and setted to a reasonable number then this will be the number of SCM (8 byte on a 64bit arch or 4 on a 32 bit arch) to allocate to the VM stack. The naming might not be the best, we might want to name it VM_STACK in stead of stack. anyway here is a patch. I tested it to the example in the beginning of this thread and it seams to work just fine. The intention is for this to be enough to close the bug. /Stefan On Wed, Dec 12, 2012 at 9:33 AM, wrote: > -[ Tue, Dec 11, 2012 at 11:29:31PM +0100, Stefan Israelsson Tampe ]---- > > 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! > > Oh, I hadn't realized you were speaking about the VM's stack. It all makes > sense now. > Any inconvenient to set this stack even bigger ? How many such stacks do we > have in a running environment ? One per thread ? > > > 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 = # > signature-id)> > > Yes, I did this and as a result the compiled function was... 20% faster !? > (note that my bench exclude the compilation time, and uses > get-internal-run-time > as a clock source). > > Thank you very much for all these advices. > As usual, support from free software community is much better than it is > from > any business I've seen :-) > > --047d7bdc1be47483b504d0aaeba0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I added a patch to suggest a new environment variabl= e.

=A0 =A0GUILE_STACK_SIZE_NSCM

=
If this is defined and setted to a reasonable number then this w= ill be the number
of SCM (8 byte on a 64bit arch or 4 on a 32 bit arch) to allocate to t= he VM stack.

The naming might not be the best, we = might want to name it VM_STACK in stead of stack.

anyway here is a patch. I tested it to the example in the beginning of this= thread and it seams
to work just fine.

= The intention is for this to be enough to close the bug.

/Stefan





On Wed, Dec 12, 201= 2 at 9:33 AM, <rixed@happyleptic.org> wrote:
-[ Tue, Dec 11, 2012 at 11:29:31PM +0100, St= efan Israelsson Tampe ]----
> 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!

Oh, I hadn't realized you were speaking about the VM's stack.= It all makes
sense now.
Any inconvenient to set this stack even bigger ? How many such stacks do we=
have in a running environment ? One per thread ?

> Then I can compile to tree-il. Compiling all the way does not work wel= l,
> But if you enter
> scheme@(guile-user)> (compile program #:to 'value #:opts '(= #:partial-eval?
> #f #:cse? #f)) =A0;;NO OPTIMIZATION PASSES
>
> It will compile to.
>
> $7 =3D #<procedure 3708400 (proto server-port client-zone server-zo= ne
> signature-id)>

Yes, I did this and as a result the compiled function was... 20% fast= er !?
(note that my bench exclude the compilation time, and uses get-internal-run= -time
as a clock source).

Thank you very much for all these advices.
As usual, support from free software community is much better than it is fr= om
any business I've seen :-)


--047d7bdc1be47483b504d0aaeba0-- --047d7bdc1be47483ba04d0aaeba2 Content-Type: application/octet-stream; name="stack-size.patch" Content-Disposition: attachment; filename="stack-size.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hamq36e60 RnJvbSAxYjRhNDlkYjg2ZmE2ZWJmNjk0MzYxM2ZlNmMxYWM5NzI4ZjcyZDMwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVmYW4gSXNyYWVsc3NvbiBUYW1wZSA8c3RlZmFuLml0YW1w ZUBnbWFpbC5jb20+CkRhdGU6IFdlZCwgMTIgRGVjIDIwMTIgMTc6Mzc6NDQgKzAxMDAKU3ViamVj dDogW1BBVENIXSB2bTogYWRkZWQgc3RhY2sgc2l6ZSBlbnZpcm9ubWVudCB2YXJpYWJsZQogR1VJ TEVfU1RBQ0tfU0laRV9OU0NNICogbGliZ3VpbGUvdm0uaCBpbiBmdW5jdGlvbiBtYWtlX3ZtICAK IGFkZGVkIGNvZGUgdG8gdXNlIGVudmlyb25tZW50IHZhcmlhYmxlIGZvciBzdGFjayBzaXplIGlm CiBkZWZpbmVkCgotLS0KIGxpYmd1aWxlL3ZtLmMgfCAgIDEzICsrKysrKysrKysrKy0KIDEgZmls ZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEv bGliZ3VpbGUvdm0uYyBiL2xpYmd1aWxlL3ZtLmMKaW5kZXggNWRlYzEwNi4uYWRkZTAwZCAxMDA2 NDQKLS0tIGEvbGliZ3VpbGUvdm0uYworKysgYi9saWJndWlsZS92bS5jCkBAIC02NzAsNyArNjcw LDE4IEBAIG1ha2Vfdm0gKHZvaWQpCiAKICAgdnAgPSBzY21fZ2NfbWFsbG9jIChzaXplb2YgKHN0 cnVjdCBzY21fdm0pLCAidm0iKTsKIAotICB2cC0+c3RhY2tfc2l6ZSAgPSBWTV9ERUZBVUxUX1NU QUNLX1NJWkU7CisgIHNpemVfdCBzc3ogPSBWTV9ERUZBVUxUX1NUQUNLX1NJWkU7CisgIFNDTSBl bnZfc3RhY2tfc2l6ZSA9IHNjbV9nZXRlbnYoIHNjbV9mcm9tX2xvY2FsZV9zdHJpbmcgKCJHVUlM RV9TVEFDS19TSVpFX05TQ00iKSk7CisgIAorICBpZiAoc2NtX2lzX3RydWUgKGVudl9zdGFja19z aXplKSkKKyAgICB7CisgICAgICBlbnZfc3RhY2tfc2l6ZSA9IHNjbV9zdHJpbmdfdG9fbnVtYmVy IChlbnZfc3RhY2tfc2l6ZSwgc2NtX2Zyb21faW50ICgxMCkpOworICAgICAgaWYoc2NtX2lzX3Ry dWUgKGVudl9zdGFja19zaXplKSAKKyAgICAgICAgICYmIHNjbV9pc191bnNpZ25lZF9pbnRlZ2Vy IChlbnZfc3RhY2tfc2l6ZSwgMTAwMCwgMjAwMDAwMDAwMCkpCisgICAgICAgIHNzeiA9IHNjbV90 b191aW50MzIgKGVudl9zdGFja19zaXplKTsKKyAgICB9CisKKyAgdnAtPnN0YWNrX3NpemUgID0g c3N6OwogCiAjaWZkZWYgVk1fRU5BQkxFX1BSRUNJU0VfU1RBQ0tfR0NfU0NBTgogICB2cC0+c3Rh Y2tfYmFzZSA9IChTQ00gKikKLS0gCjEuNy45LjUKCg== --047d7bdc1be47483ba04d0aaeba2--