unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Joe Wells <jbw@macs.hw.ac.uk>
Cc: bug-gnu-emacs@gnu.org
Subject: Re: frames vs. weak hash tables and garbage collection
Date: Fri, 28 Sep 2007 14:22:09 -0400	[thread overview]
Message-ID: <jwvy7eqzmiz.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <86sl4yybst.fsf@macs.hw.ac.uk> (Joe Wells's message of "Fri\, 28 Sep 2007 17\:50\:10 +0100")

>> 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




  reply	other threads:[~2007-09-28 18:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30  1:27 frames vs. weak hash tables and garbage collection Joe Wells
2007-08-30  2:07 ` Eric Hanchrow
2007-08-30  3:00 ` Thien-Thi Nguyen
2007-08-30  3:07 ` Thien-Thi Nguyen
     [not found] ` <mailman.47.1188442895.18990.bug-gnu-emacs@gnu.org>
2007-08-31 15:15   ` Joe Wells
2007-08-31 15:42     ` Thien-Thi Nguyen
2007-08-31 15:50     ` Thien-Thi Nguyen
     [not found]     ` <mailman.116.1188575498.18990.bug-gnu-emacs@gnu.org>
     [not found]       ` <xnjir6tyj35.fsf@csb.bu.edu>
2007-09-02  2:00         ` Thien-Thi Nguyen
     [not found]     ` <mailman.115.1188574978.18990.bug-gnu-emacs@gnu.org>
     [not found]       ` <xnjhcmdyirv.fsf@csb.bu.edu>
2007-09-02  2:13         ` Thien-Thi Nguyen
2007-09-25 23:23     ` Joe Wells
2007-09-27  7:20       ` Glenn Morris
2007-09-27  8:50         ` Thien-Thi Nguyen
     [not found]           ` <mailman.1408.1190931512.18990.bug-gnu-emacs@gnu.org>
2007-09-28 14:34             ` Stefan Monnier
2007-09-28 14:56               ` Joe Wells
2007-09-28 16:27                 ` Stefan Monnier
2007-09-28 16:50                   ` Joe Wells
2007-09-28 18:22                     ` Stefan Monnier [this message]
2007-09-28 18:48                       ` Joe Wells
2007-09-29 16:10                   ` Richard Stallman
2007-09-29 16:20                     ` Joe Wells
2007-09-29 18:28                       ` Stefan Monnier
2007-09-29 19:25                         ` Drew Adams
2007-09-30 12:55                           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvy7eqzmiz.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=jbw@macs.hw.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).