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

[Dima Kogan <dima@secretsauce.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Cc: dmantipov@yandex.ru, handa@gnu.org, 21556@debbugs.gnu.org
>> Date: Fri, 30 Oct 2015 12:17:36 -0700
>> 
>> - fonts (sometimes) live inside font-entities
>
> Can you show an example of that, or maybe even tell what path(s)
> through the code cause this to happen?  AFAICS, the backtrace you've
> shown in your last mail is not such a path: the entity there is some
> temporary object that is used to find and open a font, and can
> thereafter be forgotten.  Or did I miss something?

If you look at the font cache object as you run emacs, you should see
font-containing-entities in it.

I don't believe the entity in that backtrace is temporary. The code is:

    Lisp_Object
    font_list_entities (struct frame *f, Lisp_Object spec)
    {
      .....
                val = driver_list->driver->list (f, scratch_font_spec);
                if (!NILP (val))
                  {
                    Lisp_Object copy = copy_font_spec (scratch_font_spec);

                    val = Fvconcat (1, &val);
                    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
                    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
                  }
      .....


The driver_list->driver->list() call is the one in the backtrace. As you
can see, the results of that call are stored in the font cache. The
questions for Dmitry (or you, Eli, if you know the answer) are

    1. does it make sense that Vfontset_table has no entities in it, and
    thus does not mark them?

    2. what, if anything, should be marking the entities? I'm not seeing
    anything marking them

If the observed behavior is correct (nothing marking the entities), then
the patch in this report is correct also, and we should install it.