bug#18162: 24.3.92; segfault on null face pointer in face_for_char

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@permabit.com>
> Date: Thu, 31 Jul 2014 19:24:13 -0400
> 
> (gdb) fr 6
> #6  face_for_char (f=0x66f0858, face=0x0, c=8230, pos=-1, object=13137010) at fontset.c:914
> 914	  eassert (fontset_id_valid_p (face->fontset));
> (gdb) up
> #7  0x0000000000619155 in Finternal_char_font (position=<optimized out>, ch=<optimized out>) at fontset.c:1863
> 1863	  face_id = FACE_FOR_CHAR (f, FACE_FROM_ID (f, face_id), c, pos, Qnil);
> (gdb)
> 
> The incoming face_id value was optimized out, but since "position" is
> nil (from looking in the caller's frame), it should've been assigned
> from lookup_basic_face(f,DEFAULT_FACE_ID), and since
> Vface_remapping_alist is nil, that would just be DEFAULT_FACE_ID or 0.
> 
> c=8230 is HORIZONTAL ELLIPSIS

Where did the ellipsis character come from?  Did you have some buffer
shown in that frame that could have used this character?  According to
the last keys you show below, you were typing into minibuffer, which
is unlikely to have that character.

> pos=-1
> 
> f->face_cache points to:
> 
> $22 = {
>   buckets = 0x6122800, 
>   f = 0x66f0858, 
>   faces_by_id = 0x77a97c0, 
>   size = 112, 
>   used = 0, 
>   menu_face_changed_p = false
> }
> 
> Since "used" is 0, FACE_FROM_ID returns a null pointer, which gets
> passed to FACE_FOR_CHAR and face_for_char, and the latter assumes it's
> not a null pointer.

Sounds like some code called clear_face_cache, for some reason.  Is f
at all the same frame where you were typing?  If not, the crash could
have nothing to do with what you typed, but with some background
activity on another frame.