all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@ics.uci.edu>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: Chong Yidong <cyd@stupidchicken.com>,
	"Stephen J. Turnbull" <stephen@xemacs.org>,
	Markus Triska <markus.triska@gmx.at>,
	emacs-devel@gnu.org
Subject: Re: Memory leak in keyboard variables?
Date: Sat, 20 Dec 2008 10:37:19 -0800 (PST)	[thread overview]
Message-ID: <200812201837.mBKIbJw0027951@mothra.ics.uci.edu> (raw)
In-Reply-To: <200812201745.mBKHjbUh027877@mothra.ics.uci.edu> (Dan Nicolaescu's message of "Sat, 20 Dec 2008 09:45:37 -0800 (PST)")

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Jan Djärv <jan.h.d@swipnet.se> writes:
  > 
  >   > 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.
  > 
  > Following that logic, maybe all Lisp_Objects in struct frame need to be set to nil.

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




  reply	other threads:[~2008-12-20 18:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11  3:03 Memory leak in keyboard variables? Chong Yidong
2008-12-11  9:30 ` Andreas Schwab
2008-12-11 15:09   ` Chong Yidong
2008-12-11 20:43     ` Chong Yidong
2008-12-13 14:19       ` Markus Triska
2008-12-13 19:09         ` Chong Yidong
2008-12-16 14:11         ` Chong Yidong
2008-12-17  4:40           ` Stephen J. Turnbull
2008-12-20  1:50             ` Chong Yidong
2008-12-20 15:34               ` Jan Djärv
2008-12-20 17:09                 ` Markus Triska
2008-12-20 17:45                 ` Dan Nicolaescu
2008-12-20 18:37                   ` Dan Nicolaescu [this message]
2008-12-20 20:41                 ` Chong Yidong
2008-12-11 15:59 ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2008-12-15  1:26 Kenichi Handa
2008-12-15  3:16 ` Chong Yidong
2008-12-16  4:31   ` Kenichi Handa
2008-12-16  2:14 Chetan Pandya
2008-12-16  3:33 ` Chong Yidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200812201837.mBKIbJw0027951@mothra.ics.uci.edu \
    --to=dann@ics.uci.edu \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=jan.h.d@swipnet.se \
    --cc=markus.triska@gmx.at \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.