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 19:48:22 +0100 Message-ID: <86lkaqy6bt.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> <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 1191005328 8782 80.91.229.12 (28 Sep 2007 18:48:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2007 18:48:48 +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 20:48:42 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 1IbKt7-00028K-7p for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 20:48:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKt3-0001dT-QR for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Sep 2007 14:48:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbKt1-0001cq-MW for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:48:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbKt1-0001cO-8T for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:48:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbKt0-0001cK-UK for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:48:26 -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 1IbKt0-0003vH-Kq for bug-gnu-emacs@gnu.org; Fri, 28 Sep 2007 14:48:26 -0400 Original-Received: from selene.macs.hw.ac.uk ([137.195.27.40]:50023 helo=127.0.0.1) by izanami.macs.hw.ac.uk with smtp (Exim 4.51) id 1IbKsw-00049K-Ut; Fri, 28 Sep 2007 19:48:23 +0100 Original-Received: (nullmailer pid 10638 invoked by uid 1001); Fri, 28 Sep 2007 18:48:22 -0000 In-Reply-To: (Stefan Monnier's message of "Fri\, 28 Sep 2007 14\:22\:09 -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:16649 Archived-At: Stefan Monnier writes: >>> 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 () >> [ ... new version of code deleted ... ] >> ... ) > > 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'. It seems it is not the stack. See below. > 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. Okay. Using a recursive-edit seems to be enough: (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. (recursive-edit) ;; 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))) Evaluate (reproduce-bug) and type C-M-c (exit-recursive-edit) in the recursive edit, and it correctly returns nil. (By the way, I tried doing (setq unread-command-events (append (kbd "C-M-c") nil)) just before the recursive edit, but that wasn't enough. It needs to have real user interaction. I'm curious if there is some purely programmatic way of simulating the effects of a recursive edit with only C-M-c typed in it, because this would help in building test cases.) Conclusion: There is no bug with garbage collection of deleted frames, but merely the appearance of a bug, because the recent event array keeps the frame alive for a while. Thanks for tracking down the cause of the appearance of a bug! -- Joe