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

[Ken Raeburn <raeburn@permabit.com>]

I just tested on a machine without any of the patches, and was able to reproduce the crash. I'm not sure what else about my environment is likely to be different from yours...

On Aug 2, 2014, at 08:50, Eli Zaretskii <eliz@gnu.org> wrote:
> Moreover, even if I force the call to clear_font_cache by invoking
> clear-font-cache in the progn, I don't see a crash, and the use count
> of the frame's face cache is not zero.
> 
> So one way of tracking this down would be to put a breakpoint in
> Fclear_face_cache, and when it breaks, step through the function until
> it assigns the frame pointer to 'f', and put a watchpoint on
> f->face_cache->used, to see which code zeroes it.  My guess would be
> that some code calls free_realized_faces (I misremembered earlier:
> clear_face_cache doesn't do that).

In the code I'm looking at, clear_face_cache can call free_all_realized_faces, but only if FRAME_DISPLAY_INFO(f)->n_fonts is larger than 10 for some frame. (And either clear_fonts_p is set, or you've made over 500 calls since the last font cache cleaning.) In my first evaluation of the lisp code I gave, the n_fonts field had the value 7; on the second evaluation it had the value 12, the cache got cleared, the null pointer was stored, and Emacs segfaulted.

I've done next to nothing with fonts and faces in Emacs source code, so I'm not sure what a good way is to drive up the number. If I run my test again without list-faces-display, the font counts I'm seeing are first 4 and then 7 for repeated evaluations, as displayed via gdb breakpoint commands. If I split the window with C-x 2 then the count goes up to 8 (new inactive mode line?). Reducing the font size (C-x -) made it jump to 14, and 15 on repeated evaluations, without triggering the problem, but when I set the font size back (C-x +) and evaluated the expression one more time, I got the crash.

Ken