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

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: enquiries <at> vsm.in, 18573 <at> debbugs.gnu.org
Subject: bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw
Date: Wed, 1 Oct 2014 19:43:11 +0200

Hi.

29 sep 2014 kl. 19:18 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> 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?

Yes.

> 
> 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.

If this code is not run for the initial tty frame, then a GUI frame made later with make-frame-on-display does not get this font.  The face is not changed for future frames.

> 
> 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?

There is a fundamental error here.  Emacs allows specifying face attributes for future GUI frames when only non-GUI frames exists.  But those attributes requires GUI frames to be realized.
We are missing a "lazy" realization that only saves the text version of the attribute and realizes only when an apropriate frame is available.

For now I comitted the "wont crash" solution (don't execute the code for tty frames) in the emacs 24 branch.  No error is signalled and no looping is done to find a GUI frame.  I'm not sure if we should do that.

	Jan D.

Previous Next

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