bug#21556: 25.0.50; Memory leak in emacs -Q with lucid (font)

[Dima Kogan <dima@secretsauce.net>]

Hi. This is similar to, but different from
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21509

On my machine if I open a daemon with emacs -Q, and start/stop clients
as described in the previous report, I see one font leaking with every
frame. With one exception (below), everything that is cleaned out, is
cleaned with x_delete_terminal() where all fonts in emacs's font cache
are cleared.

The bug appears to be that something is resetting emacs's font cache at
some point during frame creation, and any fonts that were cached before
that point end up leaking. With a breakpoint at font_load_for_lface() I
print the font cache. font_load_for_lface() is called 4 times during
frame creation, and the caches look like this:


(":0.0" (x 1) (xft 1))
(":0.0" (x 1)
  (xft 1
    (#<font-spec xft nil Monospace nil iso8859-1 nil nil nil nil nil nil nil ((:name . "monospace-10"))> .
      [#<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 bold oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-BoldOblique.ttf" . 0) (:name . "monospace-10"))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 bold normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf" . 0) (:name . "monospace-10"))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf" . 0) (:name . "monospace-10"))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 normal oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Oblique.ttf" . 0) (:name . "monospace-10"))>])))
(":0.0" (x 1) (xft 1))
(":0.0" (x 1)
  (xft 1
    (#<font-spec xft unknown DejaVu\ Sans\ Mono nil iso8859-1 nil nil nil nil nil nil nil nil> .
      [#<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 bold oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-BoldOblique.ttf" . 0))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 bold normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf" . 0))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf" . 0))>
       #<font-entity xft unknown DejaVu\ Sans\ Mono nil iso10646-1 normal oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Oblique.ttf" . 0))>])))


Note that this cache is reset between the 2nd and 3rd calls without the
corresponding font being freed. I cannot tell where this is being
cleared; all the suspect breakpoints aren't hitting. Main question of
this bug report so far:




  Is there a way to put a watchpoint on a lisp object? How?




I'm observing that most (but not all) of the time, the menu font is
being created around the same time as the cache reset. Backtrace:

	    7fcf06d1e99f XftFontOpenName (/usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
	          6b5861 openXftFont (/tmp/emacs-tst)
	          6b5999 XlwMenuInitialize (/tmp/emacs-tst)
	    7fcf07ac9e2c [unknown] (/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
	    7fcf07aca7c8 [unknown] (/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
	    7fcf07acac18 _XtCreateWidget (/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
	    7fcf07acaefd XtCreateWidget (/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
	          6b01f3 xlw_create_menubar (/tmp/emacs-tst)
	          6af1d3 instantiate_widget_instance (/tmp/emacs-tst)
	          6ae462 allocate_widget_instance (/tmp/emacs-tst)
	          6af306 lw_make_widget (/tmp/emacs-tst)
	          6af392 lw_create_widget (/tmp/emacs-tst)
	          4974b9 set_frame_menubar (/tmp/emacs-tst)
	          497673 initialize_frame_menubar (/tmp/emacs-tst)
	          5358f5 Fx_create_frame (/tmp/emacs-tst)

This font allocation doesn't read or write to the frame cache, and has
its own font-cleanup call that appears to work. I cannot find any
explicit evidence that this clears out the font cache, but turning off
the menu with M-x menu-bar-mode makes this leak mostly go away.