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

[Dima Kogan]

Dmitry Antipov <dmantipov@yandex.ru> writes:

> On 09/29/2015 12:28 PM, Dima Kogan wrote:
>
>> I found and fixed the bug, and the patch is attached. The issue was
>> that the compaction code wasn't checking all the right lisp objects
>> for the marks. The font entities were storing a list of fonts, and
>> this list had to be traversed, looking for the marks.
>
> In general, this patch hits the case where the font object is marked but the
> corresponding font entity is not; but is that legal? IIRC Emacs asks the font
> driver to find a font described by font spec, and returned object is a font 
> entity,
> which is a list of font objects plus some extra stuff. Thus, there should be
> no "free-floating" font objects, i.e. for each font object, there should be
> at least one font entity object which references that font. IOW, having
> marked font object without marked font entity looks like GC mark bug for me.

OK. The target of the patch is as you describe: fonts marked inside an
unmarked entity. I'm observing this situation every time from an emacs
-Q. The font is marked inside mark_face_cache(), which looks like this:


   NO_INLINE /* To reduce stack depth in mark_object.  */
   static void
   mark_face_cache (struct face_cache *c)
   {
     if (c)
       {
         int i, j;
         for (i = 0; i < c->used; ++i)
           {
             struct face *face = FACE_FROM_ID (c->f, i);

             if (face)
               {
                 if (face->font && !VECTOR_MARKED_P (face->font))
                   mark_vectorlike ((struct Lisp_Vector *) face->font);

                 for (j = 0; j < LFACE_VECTOR_SIZE; ++j)
                   mark_object (face->lface[j]);
               }
           }
       }
   }


Clearly in this function we mark the font. We don't obviously mark the
containing entity, unless it's one of the face->lface[] elements. If
even in this case we're supposed to be marking the entity, where would
this be?