bug#18573: 24.3.93; set-face-attribute crashes Emacs on OS X 10.9.4

bug#18573: 24.3.93; set-face-attribute crashes Emacs on OS X 10.9.4

[enquiries]

When launched via terminal (cli), Emacs crashes by just having this 
single line in init.el:

(set-face-attribute 'default nil :font  "Menlo-16")

Emacs does /not/ crash when launched from the Finder (same init.el)


I am using GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0, NS 
apple-appkit-1265.21) of 2014-08-15 on builder10-9.porkrind.org on OS X 
10.9.4


Sam Ask





In GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
  of 2014-08-15 on builder10-9.porkrind.org
Windowing system distributor `Apple', version 10.3.1265
Configured using:
  `configure --with-ns'

Important settings:
   locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x e m a c s b u <tab> <backspace> <backspace> - b
u g - r e p o r t <return> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> r e
p o r t <tab> <return>

Recent messages:
Loading /Users/sam/.emacs.d/init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
delete-backward-char: Text is read-only

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils cl gv cl-loaddefs
cl-lib time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process cocoa ns
multi-tty emacs)

Memory information:
((conses 16 75113 4885)
  (symbols 48 17760 0)
  (miscs 40 78 113)
  (strings 32 10523 3551)
  (string-bytes 1 303408)
  (vectors 16 9703)
  (vector-slots 8 378700 13839)
  (floats 8 53 97)
  (intervals 56 214 0)
  (buffers 960 12))

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

[Jan Djärv]

Hello.

27 sep 2014 kl. 18:13 skrev enquiries@vsm.in:

> 
> When launched via terminal (cli), Emacs crashes by just having this single line in init.el:
> 
> (set-face-attribute 'default nil :font  "Menlo-16")
> 
> Emacs does /not/ crash when launched from the Finder (same init.el)
> 

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.

	Jan D.

> I am using GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21) of 2014-08-15 on builder10-9.porkrind.org on OS X 10.9.4
> 
> 
> Sam Ask
> 
> 
> 
> 
> 
> In GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
> of 2014-08-15 on builder10-9.porkrind.org
> Windowing system distributor `Apple', version 10.3.1265
> Configured using:
> `configure --with-ns'
> 
> Important settings:
>  locale-coding-system: utf-8-unix
> 
> Major mode: Fundamental
> 
> Minor modes in effect:
>  tooltip-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  blink-cursor-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  buffer-read-only: t
>  line-number-mode: t
>  transient-mark-mode: t
> 
> Recent input:
> M-x e m a c s b u <tab> <backspace> <backspace> - b
> u g - r e p o r t <return> <backspace> <backspace>
> <backspace> <backspace> <backspace> <backspace> <backspace>
> <backspace> <backspace> <backspace> <backspace> <backspace>
> <backspace> <backspace> <backspace> <backspace> r e
> p o r t <tab> <return>
> 
> Recent messages:
> Loading /Users/sam/.emacs.d/init.el (source)...done
> For information about GNU Emacs and the GNU system, type C-h C-a.
> delete-backward-char: Text is read-only
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort gnus-util mail-extr emacsbug message cl-macs format-spec
> rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
> rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
> ietf-drums mm-util help-fns mail-prsvr mail-utils cl gv cl-loaddefs
> cl-lib time-date tooltip electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
> fringe tabulated-list newcomment lisp-mode prog-mode register page
> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
> syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
> vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
> romanian slovak czech european ethiopic indian cyrillic chinese
> case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
> loaddefs button faces cus-face macroexp files text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process cocoa ns
> multi-tty emacs)
> 
> Memory information:
> ((conses 16 75113 4885)
> (symbols 48 17760 0)
> (miscs 40 78 113)
> (strings 32 10523 3551)
> (string-bytes 1 303408)
> (vectors 16 9703)
> (vector-slots 8 378700 13839)
> (floats 8 53 97)
> (intervals 56 214 0)
> (buffers 960 12))
> 
> 

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

[enquiries]

On 28/09/2014 10:44, Jan Djärv wrote:
> Hello.
>
> 27 sep 2014 kl. 18:13 skrev enquiries@vsm.in:
>
>>
>> When launched via terminal (cli), Emacs crashes by just having this single line in init.el:
>>
>> (set-face-attribute 'default nil :font  "Menlo-16")
>>
>> Emacs does /not/ crash when launched from the Finder (same init.el)
>>
>
> 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.
>
> 	Jan D.


Hi,

Thank you, that sounds like the reason, although I am not fluent with C 
nor gdb to check and confirm it.

I can add that Emacs just crashes printing this error:

Fatal error 11: Segmentation fault[1] 51512 abort 
/Applications/Emacs.app/Contents/MacOS/Emacs -nw

Also, if that line is wrapped with condition-case err, like this:

(condition-case err (set-face-attribute 'default nil :font "Menlo-16") 
(error (message "Whoops!")))

I experience the same crash with same error message. No additional 
elisp-originating messages.


I have tried with GNU Emacs 24.3.1 (x86_64-apple-darwin, NS 
apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org, from 
emacsformacosx.com, and Emacs does not crash. So, it must be a bug in 
later versions.

I am of course aware that in any case Emacs will inherit whatever font 
and font size is specified in the terminal app (basically, that line is 
not meaningful in the cli).

Sam

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

[Glenn Morris]

"enquiries@vsm.in" wrote:

> I have tried with GNU Emacs 24.3.1 (x86_64-apple-darwin, NS
> apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org, from
> emacsformacosx.com, and Emacs does not crash.

So should this be fixed in emacs-24, and should the pretest wait for it?

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

[Stefan Monnier]

>> I have tried with GNU Emacs 24.3.1 (x86_64-apple-darwin, NS
>> apple-appkit-1038.36) of 2013-03-13 on bob.porkrind.org, from
>> emacsformacosx.com, and Emacs does not crash.
> So should this be fixed in emacs-24,

Yes.

> and should the pretest wait for it?

Depends if there's an easy quick fix.


        Stefan

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

[Eli Zaretskii]

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

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

[enquiries]

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

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

[Jan Djärv]

Hi.

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

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

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.

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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 1 Oct 2014 19:43:11 +0200
> Cc: enquiries@vsm.in,
>  18573@debbugs.gnu.org
> 
> > 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.

If the frame argument is t, we could try looking for a GUI frame; that
way, we would signal an error in fewer cases.  After all, using the
selected frame is arbitrary.

At the very least, I think we should have a FIXME comment there
describing the problem.

Thanks.

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

[Jan Djärv]

1 okt 2014 kl. 19:49 skrev Eli Zaretskii <eliz@gnu.org>:

> If the frame argument is t, we could try looking for a GUI frame; that
> way, we would signal an error in fewer cases.  After all, using the
> selected frame is arbitrary.
> 
> At the very least, I think we should have a FIXME comment there
> describing the problem.

I added a comment.

	Jan D.

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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 1 Oct 2014 20:11:34 +0200
> Cc: enquiries@vsm.in,
>  18573@debbugs.gnu.org
> 
> 
> 1 okt 2014 kl. 19:49 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > If the frame argument is t, we could try looking for a GUI frame; that
> > way, we would signal an error in fewer cases.  After all, using the
> > selected frame is arbitrary.
> > 
> > At the very least, I think we should have a FIXME comment there
> > describing the problem.
> 
> I added a comment.

Thanks.

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

[Stefan Kangas]

fixed 18573 24.4
close 18573
quit

Jan Djärv <jan.h.d@swipnet.se> writes:

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

I think that fixed the issue; I can no longer reproduce it.

I don't see anything else outstanding, besides the FIXME added in:

commit 335e9627ca78f7be9eea27f38a530fd51a1e6995
Author: Jan Djärv <jan.h.d@swipnet.se>
Date:   Wed Oct 1 20:10:21 2014 +0200

    * xfaces.c (Finternal_set_lisp_face_attribute): Added FIXME comment.

But that is just a possible improvement, and keeping this bug open won't
do much to help direct any efforts to doing that.  If anything it will
confuse it by mixing it up with a crash that has been fixed for a long
time.

I'm therefore closing this bug.  If anyone disagrees, feel free to
reopen.

Best regards,
Stefan Kangas