From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joe Wells Newsgroups: gmane.emacs.bugs Subject: Re: frames vs. weak hash tables and garbage collection Date: Fri, 28 Sep 2007 17:50:10 +0100 Message-ID: <86sl4yybst.fsf@macs.hw.ac.uk> References: <86wsvdvmkb.fsf@macs.hw.ac.uk> <86y7fru45n.fsf@macs.hw.ac.uk> <868x6u1g8x.fsf@macs.hw.ac.uk> <874phgo5l2.fsf@ambire.localdomain> <86k5qazvm4.fsf@macs.hw.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1190998236 18014 80.91.229.12 (28 Sep 2007 16:50:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2007 16:50:36 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 28 18:50:32 2007 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IbJ2m-0007dy-K7 for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 18:50:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbJ2i-0008Cq-UV for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 12:50:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbJ2g-0008AP-8D for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 12:50:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbJ2e-00088U-OP for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 12:50:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbJ2e-00088F-GY for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 12:50:16 -0400 Original-Received: from izanami.macs.hw.ac.uk ([137.195.13.6]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IbJ2d-0004Xd-TW for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 12:50:16 -0400 Original-Received: from selene.macs.hw.ac.uk ([137.195.27.40]:49993 helo=127.0.0.1) by izanami.macs.hw.ac.uk with smtp (Exim 4.51) id 1IbJ2c-0007oQ-JF; Fri, 28 Sep 2007 17:50:14 +0100 Original-Received: (nullmailer pid 29758 invoked by uid 1001); Fri, 28 Sep 2007 16:50:10 -0000 In-Reply-To: (Stefan Monnier's message of "Fri\, 28 Sep 2007 12\:27\:20 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:16646 Archived-At: Stefan Monnier writes: >> Your explanation doesn't show up in gnu.emacs.bug either. Can you >> please resend? > > Hmm... not sure what's going on. There's not much more to send. > >> By the way, great work in tracking the problem down! > > Thanks. > >> I suppose this means frames are never being garbage collected at all? > > Not at all: the array of recent input events (as the name implies) only k= eep > recent events, so after some number of events (300, more precisely) the > reference disappears, making it possible to collect the frame. Ah! So this is some sort of =E2=80=9Creverse heisenbug=E2=80=9D which only show= s up when you look for bugs right away? > The reference from `values' is just due to the fact that you run > `reproduce-bug' from M-: and that its return value contains the frame, so > it's a rather unusual circumstance. I'm confused. The frame can only show up in values if it fails to be garbage collected for another reason. The frame should already have been garbage collected before the expression finished evaluation and hence should never get into values. So in my case it must be the recent events array which was the cause of the appearance of a failure to garbage collect. (I suppose your point is that if one ever tests garbage collection behavior with M-: (eval-expression), then there is a high likelihood of getting confused. Personally, I usually evaluate expressions with C-x C-e (eval-last-sexp), which does not add to values.) Anyway, although I can see that the recent events array would be enough to cause the problem, I'm not sure it is the only cause. If I understand correctly, the array you are talking about is recent_keys which is cleared by clear-this-command-keys. However, I still get the bug when I insert a use of clear-this-command-keys into the bug reproduction code: (defun reproduce-bug () (let ((ht (make-hash-table :weakness 'key))) (let ((x (make-frame) ;;(get-buffer-create "xyzzy") )) (puthash x t ht) (delete-frame x) ;;(kill-buffer x) ) ;; Give time for various frame related events to be handled, in ;; case this is needed. (sit-for 1) ;; There may be a reference to the frame in the array of recent ;; events, so we clear this array. (clear-this-command-keys) ;; In theory, the only reference to the new frame is now the key ;; in the hash table. Because of the weakness, this key should ;; not keep the frame alive. (garbage-collect) ;; The hash table should now be empty. (let (l) (maphash (lambda (k v) (push (cons k v) l)) ht) l))) Is there another array of recent events different from recent_keys? > But it seems that `values' is never flushed, so it is a source of leaks. > We should probably fix it (I'd remove it since almost noone even knows th= at > it exists, but I guess Richard uses it once in a blue moon). Perhaps it should have a length limit at least? --=20 Joe