Re: Memory leak in keyboard variables?

[Dan Nicolaescu]

Dan Nicolaescu <address@hidden> writes:

  > Jan Djärv <address@hidden> writes:
  > 
  >   > Chong Yidong skrev:
  >   > > "Stephen J. Turnbull" <address@hidden> writes:
  >   > > 
  >   > >> Chong Yidong writes:
  >   > >>  > Markus Triska <address@hidden> 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.
  > 
  > Following that logic, maybe all Lisp_Objects in struct frame need to be set 
to nil.

Ignore this, Jan's patch is enough...