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.