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))
next prev 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.