bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw
Date: Mon, 29 Sep 2014 19:34:04 +0200

On 29/09/2014 19:18, Eli Zaretskii wrote:
From: Jan Djärv <address@hidden>
Date: Sun, 28 Sep 2014 10:44:15 +0200
Cc: address@hidden

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]