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 09:45:37 -0800 (PST)	[thread overview]
Message-ID: <200812201745.mBKHjbUh027877@mothra.ics.uci.edu> (raw)
In-Reply-To: <494D10A1.1000905@swipnet.se> ("Jan Djärv"'s message of "Sat, 20 Dec 2008 16:34:57 +0100")

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.
I did that:


Index: frame.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/frame.c,v
retrieving revision 1.402
diff -u -3 -p -u -p -r1.402 frame.c
--- frame.c   20 Dec 2008 15:59:50 -0000        1.402
+++ frame.c   20 Dec 2008 17:41:35 -0000
@@ -1632,6 +1628,27 @@ But FORCE inhibits this too.  */)
   kb->Vdefault_minibuffer_frame = Qnil;
     }
 
+  f->name = Qnil;
+  f->icon_name = Qnil;
+  f->title = Qnil;
+  f->focus_frame = Qnil;
+  f->root_window = Qnil;
+  f->selected_window = Qnil;
+  f->minibuffer_window = Qnil;
+  f->param_alist = Qnil;
+  f->scroll_bars = Qnil;
+  f->condemned_scroll_bars = Qnil;
+  f->menu_bar_items = Qnil;
+  f->face_alist = Qnil;
+  f->buffer_predicate = Qnil;
+  f->buffer_list = Qnil;
+  f->buried_buffer_list = Qnil;
+  f->menu_bar_window = Qnil;
+  f->tool_bar_window = Qnil;
+  f->tool_bar_items = Qnil;
+  f->desired_tool_bar_string = Qnil;
+  f->current_tool_bar_string = Qnil;
+
   /* Cause frame titles to update--necessary if we now have just one frame.  */
   update_mode_lines = 1;
 
and now this version of the test code above:

(dotimes (i 15)
  (let* ((params '((window-system . nil)
                   (menu-bar-lines . 1)
                   (tool-bar-lines . 1)))
         frame)
    (setq frame (x-create-frame params))
    (delete-frame frame)
    (with-current-buffer "*scratch*"
      (insert (format "%S\n"
                    (garbage-collect))))))

shows:

((66416 . 11688) (13589 . 0) (688 . 250) 147723 356072 (122 . 9) (455 . 907) (8425 . 3608))
((66423 . 11306) (13589 . 0) (688 . 247) 147717 356093 (122 . 9) (456 . 906) (8424 . 3609))
((66425 . 11304) (13589 . 0) (688 . 247) 147717 356114 (122 . 9) (457 . 905) (8424 . 3609))
((66427 . 11302) (13589 . 0) (688 . 247) 147717 356135 (122 . 9) (458 . 904) (8424 . 3609))
((66429 . 11300) (13589 . 0) (688 . 247) 147717 356156 (122 . 9) (459 . 903) (8424 . 3609))
((66431 . 11298) (13589 . 0) (688 . 247) 147717 356177 (122 . 9) (460 . 902) (8424 . 3609))
((66433 . 11296) (13589 . 0) (688 . 247) 147717 356198 (122 . 9) (461 . 901) (8424 . 3609))
((66435 . 11294) (13589 . 0) (688 . 247) 147717 356219 (122 . 9) (462 . 900) (8424 . 3609))
((66437 . 11292) (13589 . 0) (688 . 247) 147717 356240 (122 . 9) (463 . 899) (8424 . 3609))
((66439 . 11290) (13589 . 0) (688 . 247) 147717 356261 (122 . 9) (464 . 898) (8424 . 3609))
((66441 . 11288) (13589 . 0) (688 . 247) 147717 356282 (122 . 9) (465 . 897) (8424 . 3609))
((66443 . 11286) (13589 . 0) (688 . 247) 147717 356303 (122 . 9) (466 . 896) (8424 . 3609))
((66445 . 11284) (13589 . 0) (688 . 247) 147717 356324 (122 . 9) (467 . 895) (8424 . 3609))
((66447 . 11282) (13589 . 0) (688 . 247) 147717 356345 (122 . 9) (468 . 894) (8424 . 3609))
((66449 . 11280) (13589 . 0) (688 . 247) 147717 356366 (122 . 9) (469 . 893) (8424 . 3609))

before the above change it was showing:

((66496 . 11612) (13589 . 0) (691 . 250) 147758 356390 (123 . 8) (455 . 907) (8431 . 3602))
((66593 . 11390) (13589 . 0) (695 . 243) 147800 356777 (123 . 8) (456 . 906) (8437 . 3596))
((66685 . 11298) (13589 . 0) (699 . 243) 147848 357164 (123 . 8) (457 . 905) (8444 . 3589))
((66777 . 11206) (13589 . 0) (703 . 243) 147896 357551 (123 . 8) (458 . 904) (8451 . 3582))
((66869 . 11114) (13589 . 0) (707 . 243) 147944 357938 (123 . 8) (459 . 903) (8458 . 3575))
((66961 . 11022) (13589 . 0) (711 . 243) 147992 358325 (123 . 8) (460 . 902) (8465 . 3568))
((67053 . 10930) (13589 . 0) (715 . 243) 148040 358712 (123 . 8) (461 . 901) (8472 . 3561))
((67145 . 10838) (13589 . 0) (719 . 243) 148088 359099 (123 . 8) (462 . 900) (8479 . 3554))
((67237 . 10746) (13589 . 0) (723 . 243) 148136 359486 (123 . 8) (463 . 899) (8486 . 3547))
((67329 . 10654) (13589 . 0) (727 . 201) 148184 359873 (123 . 8) (464 . 898) (8493 . 3540))
((67421 . 10562) (13589 . 0) (731 . 201) 148232 360260 (123 . 8) (465 . 897) (8500 . 3533))
((67513 . 10470) (13589 . 0) (735 . 201) 148280 360647 (123 . 8) (466 . 896) (8507 . 3526))
((67605 . 10378) (13589 . 0) (739 . 201) 148328 361034 (123 . 8) (467 . 895) (8514 . 3519))
((67697 . 10286) (13589 . 0) (743 . 201) 148376 361421 (123 . 8) (468 . 894) (8521 . 3512))
((67789 . 10194) (13589 . 0) (747 . 201) 148424 361808 (123 . 8) (469 . 893) (8528 . 3505))




  parent reply	other threads:[~2008-12-20 17:45 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 [this message]
2008-12-20 18:37                   ` Dan Nicolaescu
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=200812201745.mBKHjbUh027877@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.