Re: Memory leak in keyboard variables?

[Chong Yidong <cyd@stupidchicken.com>]

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