bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode

[Jan Djärv]

Hello.

25 nov 2012 kl. 06:30 skrev Chong Yidong <cyd@gnu.org>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>>> The problem was that ns-win created fontsets unconditionally during
>>> load and that lead to problems when running with -nw, in
>>> face_for_char.  Shouldn't fontsets/font objects be ignored if the
>>> terminal is a non-GUI one?
> 
> Yep.  Thanks for finding and fixing the bug.

Actually it is not quite fixed, and not NS-specific either.
On a X11-emacs, do this (tried with Gtk2, 3 and Lucid, no difference):

% emacs -Q --daemon
% emacsclient -c &
% emacsclient -c -t

In the second, non-GUI frame do (from this bug):
u C-x 8 <RET> 0303 <RET> C-b C-u C-x =

The emacs daemon crashes, the same way as the original bug does.
This is because the emacsclient -c creates fontsets, and emacsclient -c -t 
tries to use them.

So this is a more generic problem.  The fix I made was to initialize fontsets 
in ns-win.el the same way x-win.el does, but this just hides the problem for 
the daemon case.

        Jan D.

> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> Indeed, it they should.
>> 
>> How did the code arrive at internal-char-font in this case?  The
>> backtrace indicates it was from Lisp, so can you post a Lisp
>> backtrace?
> 
> See below.  I'm not sure why describe-char-padded-string needs
> internal-char-font for, though.
> 
> "internal-char-font" (0xffffafa0)
> "if" (0xffffb238)
> "describe-char-padded-string" (0xffffb478)
> "mapconcat" (0xffffb640)
> "concat" (0xffffb8b8)
> "setcar" (0xffffba38)
> "if" (0xffffbc08)
> "if" (0xffffbe28)
> "let" (0xffffc0e8)
> "catch" (0xffffc458)
> "or" (0xffffc628)
> "progn" (0xffffc7f8)
> "if" (0xffffc9c8)
> "let*" (0xffffcc58)
> "let" (0xffffcf08)
> "describe-char" (0xffffd120)
> "what-cursor-position" (0xffffd698)
> "call-interactively" (0xffffd9b8)