Re: Memory leak in keyboard variables?

["Jan Djärv" <jan.h.d@swipnet.se>]

Chong Yidong skrev:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
>> Chong Yidong writes:
>>  > Markus Triska <markus.triska@gmx.at> writes:
>>  > 
>>  > > Please also try emacsclient with "-c" instead of "-t" - there seems to
>>  > > be a probably different and still quite big leak there as will.
>>  > 
>>  > With the recent fix to font_clear_cache, the leak is reduced to 30-40k
>>  > per frame.  This leak seems to be tied to GTK and X toolkits somehow.
>>  > It does not appear when Emacs is compiled with --with-x-toolkit=no.
>>
>> The toolkits undoubtedly do their own font caching, and probably won't
>> release the space until Emacs exits.
> 
> Yes, this is a possibility.
> 
> Another data point: the leak occurs when the menu-bar is enabled, but
> not when the menu-bar is disabled.  It's not necessary to see the leak
> using Emacsclient, as ordinary frame creating/deletion shows it:
> 
> (dotimes (i 15)
>   (let* ((params '((window-system . x)
>                    (menu-bar-lines . 1)
>                    (tool-bar-lines . 1)))
>          frame)
>     (setq frame (x-create-frame params))
>     (delete-frame frame)
>     (garbage-collect)))
> 
> I have not been able to track down the source of this leak within Emacs.
> As far as I can tell, the existing menu-bar items allocation functions
> (in xmenu.c, menu.c, keyboard.c, and gtkutil.c) free all the memory they
> allocate, yet about 10k of memory remains unfreed with each frame
> created.
> 

From what I see, the frames aren't garabge collected, and then neither is the
menu bar items in f->menu_bar_vector, which isn't used for the non-toolkit case.

The frame is at least referenced from recent-keys, and maybe one more place
which I haven't found.

Setting f->menu_bar_vector to Qnil when deleting the frame improves the
situation quite a bit, I'm not sure if it totally eliminates the leak.  I've
checked in that change.

	Jan D.