[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 -
bug#18573: 24.3.93; set-face-attribute crashes Emacs when started with -nw
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
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
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
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).