From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: Re: frames vs. weak hash tables and garbage collection Date: Fri, 28 Sep 2007 14:22:09 -0400 Message-ID: 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> <86sl4yybst.fsf@macs.hw.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1191003771 3756 80.91.229.12 (28 Sep 2007 18:22:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2007 18:22:51 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Joe Wells Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 28 20:22:46 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 1IbKUA-0000tH-B5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 20:22:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKU6-0002tW-Qf for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 14:22:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbKTg-0002bg-Ai for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:22:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbKTf-0002am-Ar for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:22:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKTf-0002ad-7y for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:22:15 -0400 Original-Received: from tomts25.bellnexxia.net ([209.226.175.188] helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IbKTe-0003jU-VM for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:22:15 -0400 Original-Received: from pastel.home ([74.12.208.240]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070928182210.CKPH19497.tomts25-srv.bellnexxia.net@pastel.home> for ; Fri, 28 Sep 2007 14:22:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E772C7F80; Fri, 28 Sep 2007 14:22:09 -0400 (EDT) In-Reply-To: <86sl4yybst.fsf@macs.hw.ac.uk> (Joe Wells's message of "Fri\, 28 Sep 2007 17\:50\:10 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) 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:16648 Archived-At: >> 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. Right. In your case the reason is the recent events array. > 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. Could be, but at least it matched the behavior I saw: if I hit a key 300 times, set `values' to nil, and call garbage-collect then the hash-table entry gets deleted (I modified your test case to make the hash-table global). > (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))) No idea about this one, but it may very well be due to transient effects such as the fact that the stack is scanned conservatively, so there may still be a spurious pointer to the frame left over somewhere at the time you call `garbage-collect'. Also the sit-for is enough to cause redisplay and execution of process filters, but I'm not convinced it's enough to cause the frame events to be added to the "recent events array", so maybe these will appear after the call to clear-this-command-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 that >> it exists, but I guess Richard uses it once in a blue moon). > Perhaps it should have a length limit at least? Yes. I.e. it should be a ring. Stefan