[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memory leak in keyboard variables?
From: |
Dan Nicolaescu |
Subject: |
Re: Memory leak in keyboard variables? |
Date: |
Sat, 20 Dec 2008 09:45:37 -0800 (PST) |
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.
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))
- Re: Memory leak in keyboard variables?, (continued)
- Re: Memory leak in keyboard variables?, Andreas Schwab, 2008/12/11
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/11
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/11
- Re: Memory leak in keyboard variables?, Markus Triska, 2008/12/13
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/13
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/16
- Re: Memory leak in keyboard variables?, Stephen J. Turnbull, 2008/12/16
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/19
- Re: Memory leak in keyboard variables?, Jan Djärv, 2008/12/20
- Re: Memory leak in keyboard variables?, Markus Triska, 2008/12/20
- Re: Memory leak in keyboard variables?,
Dan Nicolaescu <=
- Re: Memory leak in keyboard variables?, Dan Nicolaescu, 2008/12/20
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/20
Re: Memory leak in keyboard variables?, Stefan Monnier, 2008/12/11
Re: Memory leak in keyboard variables?, Kenichi Handa, 2008/12/14
- Re: Memory leak in keyboard variables?, Chong Yidong, 2008/12/14
- image cache (was: Memory leak in keyboard variables?), Stefan Monnier, 2008/12/14
- Re: image cache (was: Memory leak in keyboard variables?), Eli Zaretskii, 2008/12/14
- Re: image cache, Stefan Monnier, 2008/12/15
- Re: image cache, Chong Yidong, 2008/12/15
- Re: image cache, Stefan Monnier, 2008/12/15