found 23386 24.1
found 23386 24.5
found 23386 25.0.95
tags 23386 confirmed
quit

- Emacs versions 24.1, 24.2, 24.4, 24.5 all segfault this case.
- Emacs versions 23.4 and 24.3 don't segfault, but the first frame
  shows boxes for the characters in the modeline, and still seems to
  be using the Xft font in the initial frame (subsequently created
  frames use a font from the X backend).

In all cases this error is triggerred on startup:
"frame-notice-user-settings: Font `-PfEd-DejaVu Sans
Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1' is not defined",
although only in the latter case is Emacs able to display it, otherwise
it segfaults first.

AFAICT, this it's the same bug in all versions, some happen not to
segfault by accident.

The segfault happens when using font with

  (font->driver == &xftfont_driver) &&
  ((struct xftfont_info *)font)->xftfont == NULL

Passing NULL xftfont to Xft library triggers a segfault.

The way we end up with this kind of bad font object, is that
x_set_font_backend calls font_update_drivers which eventually calls
xftfont_close which sets the xftfont field of the frame's font to NULL,
but the frame still refers to this closed object.  The chosen font is
not updated, because it's set in the frame-parameters, so when
x_set_font_backend tries to honour this choice, it gets the error "Font
... is not defined" mentioned above (the font was defined only for the
xft backend, not the remaining x backend), and leaves the invalid font
object as the frame's default font.

Here is a patch that attempts to fix the issue by resetting the font
after the backend is changed.  It does let Emacs successfully open the
frame with the new font (no funny box characters in the modeline), but
I'm not sure if it's the best way of marking the font object invalid.