bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw

["enquiries@vsm.in" <enquiries@vsm.in>]

On 29/09/2014 19:18, Eli Zaretskii wrote:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 28 Sep 2014 10:44:15 +0200
>> Cc: 18573@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?
>



That description sounds correct to me, although I have no knowledge of 
the innards of Emacs.

Signalling an error would be better than crashing of course. Still, the 
crash is not happening with prior version (GNU Emacs 24.3.1).

Sam