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#9900: local vars not cleaned Date: Sun, 30 Oct 2011 19:49:56 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001517740ae0a3fe9404b08896b1 X-Trace: dough.gmane.org 1320000664 23534 80.91.229.12 (30 Oct 2011 18:51:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2011 18:51:04 +0000 (UTC) To: 9900@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Oct 30 19:51:00 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RKaTE-00065p-HJ for guile-bugs@m.gmane.org; Sun, 30 Oct 2011 19:51:00 +0100 Original-Received: from localhost ([::1]:53971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKaTD-0002V0-SY for guile-bugs@m.gmane.org; Sun, 30 Oct 2011 14:50:59 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKaTA-0002Uk-VK for bug-guile@gnu.org; Sun, 30 Oct 2011 14:50:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKaT9-00041s-T2 for bug-guile@gnu.org; Sun, 30 Oct 2011 14:50:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKaT9-00041o-Ne for bug-guile@gnu.org; Sun, 30 Oct 2011 14:50:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RKaVC-0002nU-23 for bug-guile@gnu.org; Sun, 30 Oct 2011 14:53:02 -0400 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: Sun, 30 Oct 2011 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9900 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 9900-submit@debbugs.gnu.org id=B9900.132000072610686 (code B ref 9900); Sun, 30 Oct 2011 18:53:02 +0000 Original-Received: (at 9900) by debbugs.gnu.org; 30 Oct 2011 18:52:06 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RKaUI-0002mI-9D for submit@debbugs.gnu.org; Sun, 30 Oct 2011 14:52:06 -0400 Original-Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RKaUF-0002mB-Pu for 9900@debbugs.gnu.org; Sun, 30 Oct 2011 14:52:04 -0400 Original-Received: by iabn5 with SMTP id n5so6333815iab.3 for <9900@debbugs.gnu.org>; Sun, 30 Oct 2011 11:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tTlSkmthb3zjm+dxEjQhfb1fOWtQ4pE7WtVm68gdWO4=; b=pUkAG1N4F0jdOG3ENF2hub3uMYDBlU642UMtm1HdVmqkq/qzInpG1NVV3+f82yrZHI Wm9ezg0fEXso7vSIBWPVBrvTdqN59NprQATscPtmiVmJ6iAqd/vNLYx5Tev7Tq4eL0qc 4XU9bO6qTP7+CbsLTFhPzf9AfM8iJplRzKrdk= Original-Received: by 10.231.51.4 with SMTP id b4mr3994371ibg.99.1320000596213; Sun, 30 Oct 2011 11:49:56 -0700 (PDT) Original-Received: by 10.231.119.100 with HTTP; Sun, 30 Oct 2011 11:49:56 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 30 Oct 2011 14:53:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:5898 Archived-At: --001517740ae0a3fe9404b08896b1 Content-Type: text/plain; charset=ISO-8859-1 Sorry to spam the list. But beeing a little ignorant how guile works, makes this a discovering procedure. So locals is always allocated from the stack. This is what happens with Ians code. A program is executed and a set of locals is allocated on the stack for the duration of the loading, this means that during the whole execution of the loaded file the locals variables are below the stack pointer and hence always contains a reference from the stack to the last used objects in the local variables. This can be seen by loading the file and then do an explicit gc on the repl. and then check the guardian. Then because the sp pointer is now below the locals in the loaded file they can be gc:ed and is also returned by calls to the guardian. What can be done? 1. One can push the constructors into functions that are called from the toplevel in the code 2. One can patch guile so that used locals in let constructs are cleaned at the end of the let form in a) toplevel let b) all let So the question now is if this is going to be fixed or if it is going to be a subtle point that can trick advanced users of guile but work most of the time in the name of speed. what do you think? /Stefan --001517740ae0a3fe9404b08896b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sorry to spam the list.

But beeing a little ignorant how gui= le works, makes this a discovering procedure.

So locals is always al= located from the stack. This is what happens with Ians code.

A progr= am is executed and a set of locals is allocated on the stack for the durati= on of the loading, this means that during the
whole execution of the loaded file the locals variables are below the stack= pointer and hence always contains a reference from the stack to the last u= sed objects in the local variables. This can be seen by loading the file an= d then do an explicit gc on the repl. and then check the guardian. Then bec= ause the sp pointer is now below the locals in the loaded file they can be = gc:ed and is also returned by calls to the guardian.

What can be done?

1. One can push the constructors into function= s that are called from the toplevel in the code
2. One can patch guile s= o that used locals in let constructs are cleaned at the end of the let form= in
=A0=A0=A0 a) toplevel let
=A0=A0=A0 b) all let

So the question no= w is if this is going to be fixed or if it is going to be a subtle point th= at can trick
advanced users of guile but work most of the time in the n= ame of speed.

what do you think?

/Stefan


--001517740ae0a3fe9404b08896b1--