GNU bug report logs - #18573
24.3.93; set-face-attribute crashes Emacs on OS X 10.9.4

Previous Next

Full log

Message #14 received at 18573 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: enquiries <at> vsm.in, 18573 <at> debbugs.gnu.org
Subject: Re: bug#18573: 24.3.93;
 set-face-attribute crashes Emacs when started with -nw
Date: Mon, 29 Sep 2014 20:18:11 +0300

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sun, 28 Sep 2014 10:44:15 +0200
> Cc: 18573 <at> debbugs.gnu.org
> 
> This seems to be a generic error in xfaces.c.  It tries to load a font without checking the type
> of frame.  The type is tty, but it tries to load a font anyway, and eventually ends up in (font.c) font_pixel_size, which does:
> 
> #define FRAME_RES_Y(f)						\
>   (eassert (FRAME_WINDOW_P (f)), FRAME_DISPLAY_INFO (f)->resy)
> 
> Now, FRAME_DISPLAY_INFO for a NS compiled Emacs is
> 
> #define FRAME_DISPLAY_INFO(f) ((f)->output_data.ns->display_info)
> 
> but the frame is not an NS frame, it is a tty frame, so bad things happen.
> It is the same for X, but there it just happens to return a nonsense value, so the code continues without crashing, and eventually discovers that there are no font dirvers and the load font fails.
> 
> The code is in xfaces.c, Finternal_set_lisp_face_attribute, around line 3120 where it calls
> font_load_for_lface.
> 
> The code in question is not called if compiled for a tty (#ifdef:ed out), but it is called when the frame is a tty frame on a non-tty compiled Emacs.
> 
> I think these cases should be the same, i.e. font_load_for_lface not called for tty frames.

I believe this happens when internal-set-lisp-face-attribute is
called with its FRAME argument t, meaning change the default for new
(i.e. future) frames.  Since the code needs a frame, it just uses the
selected frame, which in this case happens to be a TTY frame.

Is that description correct?

If so, the question is how to fix this.  If we simply do nothing when
the selected frame is a TTY frame, and then create a GUI frame at some
future point, will the new default take effect?  If it will, then I
agree that the code under this condition

	      if (! FONT_OBJECT_P (value))

should not be executed when the selected frame is a TTY frame.

But if this doesn't work, then what are our alternatives?  We could
loop over all the frames looking for a GUI frame, and use that.  But
what if there's no such frame?  Signal an error?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.