[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memory leak in keyboard variables?
From: |
Chong Yidong |
Subject: |
Re: Memory leak in keyboard variables? |
Date: |
Thu, 11 Dec 2008 10:09:44 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Andreas Schwab <address@hidden> 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.
encoded-kbd-leak.png
Description: PNG image
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.
- Memory leak in keyboard variables?, Chong Yidong, 2008/12/10
- Re: Memory leak in keyboard variables?, Andreas Schwab, 2008/12/11
- Re: Memory leak in keyboard variables?,
Chong Yidong <=
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/11
- Re: Memory leak in keyboard variables?, Markus Triska, 2008/12/13
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/13
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/16
- Re: Memory leak in keyboard variables?, Stephen J. Turnbull, 2008/12/16
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/19
- Re: Memory leak in keyboard variables?, Jan Djärv, 2008/12/20
- Re: Memory leak in keyboard variables?, Markus Triska, 2008/12/20
- Re: Memory leak in keyboard variables?, Dan Nicolaescu, 2008/12/20
- Re: Memory leak in keyboard variables?, Dan Nicolaescu, 2008/12/20