From: Chong Yidong <cyd@stupidchicken.com>
To: Andreas Schwab <schwab@suse.de>
Cc: emacs-devel@gnu.org
Subject: Re: Memory leak in keyboard variables?
Date: Thu, 11 Dec 2008 10:09:44 -0500 [thread overview]
Message-ID: <87y6ymiw93.fsf@cyd.mit.edu> (raw)
In-Reply-To: <je8wqnukio.fsf@sykes.suse.de> (Andreas Schwab's message of "Thu, 11 Dec 2008 10:30:07 +0100")
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
Andreas Schwab <schwab@suse.de> writes:
>> input-decode-map is defined in keyboard.c, using DEFVAR_KBOARD. It
>> is a Lisp_Misc_Kboard_Objfwd object, and if I'm not mistaken, such
>> objects are not garbage-collected.
>
> All Objfwd types are not real objects on their own, but static markers
> to tell the evaluator to look elsewhere for the value. If the
> pointed-to object is still live then it will not be collected, of
> course.
>
>> When the terminal is killed, are its keyboard's Lisp_Misc_Kboard_Objfwd
>> objects freed?
>
> All such objects are allocated only once before dumping.
I see. Some Lisp_Objects associated with this code are definitely being
leaked, though.
After a more rigorous test, I think the problem is not in xterm.el, but
in encoded-kb.el. I used the following debug code to track how many
conses are used:
*** trunk/lisp/server.el.~1.175.~ 2008-11-18 11:53:41.000000000 -0500
--- trunk/lisp/server.el 2008-12-11 09:50:50.000000000 -0500
***************
*** 574,581 ****
--- 574,584 ----
+ (defvar my-gc-cons-tracker nil)
+
(defun server-create-tty-frame (tty type proc)
(add-to-list 'frame-inherited-parameters 'client)
+ (push (caar (garbage-collect)) my-gc-cons-tracker)
(let ((frame
With this, I found that most of the unfreed memory is coming from a
single spot in encoded-kbd-setup-keymap (encoded-kb.el:334):
((eq (coding-system-type coding) 'utf-8)
(let ((i #xC0))
(while (< i 256)
(define-key keymap
(vector i) 'encoded-kbd-self-insert-utf-8)
(setq i (1+ i))))
Attached is a graph of conses used verses number of emacsclient
terminals allocated, over a total of 100 terminal open/close iterations.
With the present code, the number of conses used grows linearly. If
that section of code is commented out, the curve is almost flat.
[-- Attachment #2: encoded-kbd-leak.png --]
[-- Type: image/png, Size: 5860 bytes --]
[-- Attachment #3: Type: text/plain, Size: 238 bytes --]
So either the way the encoded-kbd map is set up prevents
garbage-collection from working (e.g., it might set up some kind of
circular structure), or there is a bug that prevents us from freeing
keymaps associated with deleted keyboards.
next prev parent reply other threads:[~2008-12-11 15:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 3:03 Memory leak in keyboard variables? Chong Yidong
2008-12-11 9:30 ` Andreas Schwab
2008-12-11 15:09 ` Chong Yidong [this message]
2008-12-11 20:43 ` Chong Yidong
2008-12-13 14:19 ` Markus Triska
2008-12-13 19:09 ` Chong Yidong
2008-12-16 14:11 ` Chong Yidong
2008-12-17 4:40 ` Stephen J. Turnbull
2008-12-20 1:50 ` Chong Yidong
2008-12-20 15:34 ` Jan Djärv
2008-12-20 17:09 ` Markus Triska
2008-12-20 17:45 ` Dan Nicolaescu
2008-12-20 18:37 ` Dan Nicolaescu
2008-12-20 20:41 ` Chong Yidong
2008-12-11 15:59 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2008-12-15 1:26 Kenichi Handa
2008-12-15 3:16 ` Chong Yidong
2008-12-16 4:31 ` Kenichi Handa
2008-12-16 2:14 Chetan Pandya
2008-12-16 3:33 ` Chong Yidong
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y6ymiw93.fsf@cyd.mit.edu \
--to=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=schwab@suse.de \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.