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

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

[Dan Maftei]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)

emacs -Q -nw
n C-x 8 <RET> 0303 <RET> C-b C-u C-x =

This crashes emacs. I am returned to bash. "Fatal error (10)" is written to
the screen. After about 3 seconds, "Abort trap: 6" is appended to the same
line, and I am returned to the prompt.

This does not happen in the windowed version (Emacs.app)

every locale variable is en_GB.UTF-8

TERM is dumb.

This (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9172) might be of use.
It describes a similar bug on emacs 23.3 running on an xterm, but the
program does not crash.

Cheers,
Dan

[-- Attachment #2: Type: text/html, Size: 934 bytes --]

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

[Chong Yidong]

Dan Maftei <ninestraycats@gmail.com> writes:

> GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)
>
> emacs -Q -nw
> n C-x 8 <RET> 0303 <RET> C-b C-u C-x =
>
> This crashes emacs. I am returned to bash. "Fatal error (10)" is
> written to the screen. After about 3 seconds, "Abort trap: 6" is
> appended to the same line, and I am returned to the prompt.

I could on reproduce this on x86_64-unknown-linux-gnu with either Emacs
24.1 or latest emacs-24 branch.  This may be Mac-only; could someone
running on Mac OS please check?

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

[Jan Djärv]

Hello.

5 nov 2012 kl. 15:23 skrev Chong Yidong <cyd@gnu.org>:

> Dan Maftei <ninestraycats@gmail.com> writes:
> 
>> GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)
>> 
>> emacs -Q -nw
>> n C-x 8 <RET> 0303 <RET> C-b C-u C-x =
>> 
>> This crashes emacs. I am returned to bash. "Fatal error (10)" is
>> written to the screen. After about 3 seconds, "Abort trap: 6" is
>> appended to the same line, and I am returned to the prompt.
> 
> I could on reproduce this on x86_64-unknown-linux-gnu with either Emacs
> 24.1 or latest emacs-24 branch.  This may be Mac-only; could someone
> running on Mac OS please check?

Here is a backtrace.  The fontdriver does not have an encode_char function (it is NULL).
But I don't know which driver this is.  Lisp backtrace is broken it seems.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000001002b0f6a in Finternal_char_font (position=4320145466, ch=3084) at fontset.c:1886
#2  0x0000000100202c18 in Ffuncall (nargs=3, args=0x7fff5fbfc788) at eval.c:2777
#3  0x000000010026a75b in exec_byte_code (bytestr=4309734321, vector=4322711389, maxdepth=28, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:899
#4  0x0000000100203ad6 in funcall_lambda (fun=4322711477, nargs=1, arg_vector=0x7fff5fbfce30) at eval.c:3006
#5  0x0000000100202fe6 in Ffuncall (nargs=2, args=0x7fff5fbfce28) at eval.c:2823
#6  0x0000000100202251 in call1 (fn=4362368306, arg1=3084) at eval.c:2568
#7  0x000000010021097b in mapcar1 (leni=1, vals=0x7fff5fbfcf60, fn=4362368306, seq=4307596089) at fns.c:2302
#8  0x0000000100210c80 in Fmapconcat (function=4362368306, sequence=4307596089, separator=4298596513) at fns.c:2348
#9  0x0000000100202c61 in Ffuncall (nargs=4, args=0x7fff5fbfd178) at eval.c:2781
#10 0x000000010026a75b in exec_byte_code (bytestr=4309737345, vector=4322715781, maxdepth=36, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:899
#11 0x00000001002695d6 in Fbyte_code (bytestr=4309737345, vector=4322715781, maxdepth=36) at bytecode.c:474
#12 0x0000000100200cfd in eval_sub (form=4354262198) at eval.c:2145
#13 0x00000001001fddaa in internal_catch (tag=4346014154, func=0x1002004d0 <eval_sub>, arg=4354262198) at eval.c:1059
#14 0x000000010026bbf2 in exec_byte_code (bytestr=4309735793, vector=4362397189, maxdepth=84, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:1080
#15 0x0000000100203ad6 in funcall_lambda (fun=4322720557, nargs=1, arg_vector=0x7fff5fbfe0d0) at eval.c:3006
#16 0x0000000100202fe6 in Ffuncall (nargs=2, args=0x7fff5fbfe0c8) at eval.c:2823
#17 0x000000010026a75b in exec_byte_code (bytestr=4299500689, vector=4299500725, maxdepth=52, args_template=4320145466, nargs=0, args=0x0) at bytecode.c:899
#18 0x0000000100203ad6 in funcall_lambda (fun=4299500597, nargs=1, arg_vector=0x7fff5fbfe7b8) at eval.c:3006
#19 0x0000000100202fe6 in Ffuncall (nargs=2, args=0x7fff5fbfe7b0) at eval.c:2823
#20 0x00000001001fb382 in Fcall_interactively (function=4345551946, record_flag=4320145466, keys=4320195981) at callint.c:852
#21 0x0000000100202c61 in Ffuncall (nargs=4, args=0x7fff5fbfed88) at eval.c:2781
#22 0x0000000100202339 in call3 (fn=4345319866, arg1=4345551946, arg2=4320145466, arg3=4320145466) at eval.c:2599
#23 0x0000000100143fa3 in Fcommand_execute (cmd=4345551946, record_flag=4320145466, keys=4320145466, special=4320145466) at keyboard.c:10233
#24 0x000000010012ce06 in command_loop_1 () at keyboard.c:1586
#25 0x00000001001fe51a in internal_condition_case (bfun=0x10012c280 <command_loop_1>, handlers=4320212234, hfun=0x10012b7c0 <cmd_error>) at eval.c:1288
#26 0x000000010012bdaf in command_loop_2 (ignore=4320145466) at keyboard.c:1167
#27 0x00000001001fddaa in internal_catch (tag=4320208330, func=0x10012bd80 <command_loop_2>, arg=4320145466) at eval.c:1059
#28 0x000000010012bd32 in command_loop () at keyboard.c:1146
#29 0x000000010012b137 in recursive_edit_1 () at keyboard.c:778
#30 0x000000010012b38a in Frecursive_edit () at keyboard.c:842
#31 0x000000010012885f in main (argc=3, argv=0x7fff5fbff8d8) at emacs.c:1566

Lisp Backtrace:
No symbol "GCTYPEBITS" in current context.

(gdb) up
#1  0x00000001002b0f6a in Finternal_char_font (position=4320145466, ch=3084) at fontset.c:1886
(gdb) l
1881	    return Qnil;
1882	  face_id = FACE_FOR_CHAR (f, FACE_FROM_ID (f, face_id), c, pos, Qnil);
1883	  face = FACE_FROM_ID (f, face_id);
1884	  if (face->font)
1885	    {
1886	      unsigned code = face->font->driver->encode_char (face->font, c);
1887	      Lisp_Object font_object;
1888	
1889	      if (code == FONT_INVALID_CODE)
1890		return Qnil;
(gdb) p face->font->driver->encode_char
$1 = (unsigned int (*)(struct font *, int)) 0

	Jan D.

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

[Dan Maftei]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

The but is not reproducible on the following Mac build: GNU Emacs 24.1.1
(x86_64-apple-darwin12.0.0, Carbon Version 1.6.0 AppKit 1187).

Dan

On Mon, Nov 5, 2012 at 9:23 AM, Chong Yidong <cyd@gnu.org> wrote:

> Dan Maftei <ninestraycats@gmail.com> writes:
>
> > GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)
> >
> > emacs -Q -nw
> > n C-x 8 <RET> 0303 <RET> C-b C-u C-x =
> >
> > This crashes emacs. I am returned to bash. "Fatal error (10)" is
> > written to the screen. After about 3 seconds, "Abort trap: 6" is
> > appended to the same line, and I am returned to the prompt.
>
> I could on reproduce this on x86_64-unknown-linux-gnu with either Emacs
> 24.1 or latest emacs-24 branch.  This may be Mac-only; could someone
> running on Mac OS please check?
>

[-- Attachment #2: Type: text/html, Size: 1224 bytes --]

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

[Chong Yidong]

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

> Here is a backtrace.  The fontdriver does not have an encode_char
> function (it is NULL).  But I don't know which driver this is.  Lisp
> backtrace is broken it seems.

Could you do

f 1
pp face->font->driver->type

and see what font driver it is (or if there is one)?

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

[Jan Djärv]

Hello.

23 nov 2012 kl. 07:26 skrev Chong Yidong <cyd@gnu.org>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Here is a backtrace.  The fontdriver does not have an encode_char
>> function (it is NULL).  But I don't know which driver this is.  Lisp
>> backtrace is broken it seems.
> 
> Could you do
> 
> f 1
> pp face->font->driver->type
> 
> and see what font driver it is (or if there is one)?

Basically no, because

p face->font->driver
$3 = (struct font_driver *) 0x3

Uninitialized memory?

	Jan D.

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

[Chong Yidong]

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

> Basically no, because
>
> p face->font->driver
> $3 = (struct font_driver *) 0x3
>
> Uninitialized memory?

Yeah.

Could you try to debug this by stepping through face_for_char when it is
called via Finternal_char_font?  You should be able to do this by doing

b Finternal_char_font
r
[Do the recipe]
b face_for_char
c

Then, when the debugger hits the face_for_char breakpoint, step through
that function.  When the variables rfont_def and font_object get
assigned values, use pp to view their contents and see if they are
valid.

Thanks.

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

[Jan Djärv]

Hello.

This has been fixed in the trunk.
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?

	Jan D.

23 nov 2012 kl. 08:07 skrev Jan Djärv <jan.h.d@swipnet.se>:

> Hello.
> 
> 23 nov 2012 kl. 07:26 skrev Chong Yidong <cyd@gnu.org>:
> 
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>> 
>>> Here is a backtrace.  The fontdriver does not have an encode_char
>>> function (it is NULL).  But I don't know which driver this is.  Lisp
>>> backtrace is broken it seems.
>> 
>> Could you do
>> 
>> f 1
>> pp face->font->driver->type
>> 
>> and see what font driver it is (or if there is one)?
> 
> Basically no, because
> 
> p face->font->driver
> $3 = (struct font_driver *) 0x3
> 
> Uninitialized memory?
> 
> 	Jan D.
> 

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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 24 Nov 2012 18:59:54 +0100
> Cc: Dan Maftei <ninestraycats@gmail.com>, 11964-done@debbugs.gnu.org
> 
> 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?

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?

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

[Chong Yidong]

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.


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)

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)

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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 25 Nov 2012 13:18:28 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  ninestraycats@gmail.com,
>  11964@debbugs.gnu.org
> 
> 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.

It is wrong to call internal-char-font on a non-GUI frame; for
starters, that function might not be compiled in, e.g. if Emacs was
configured --without-x.  All the other callers of that function are
careful not to do that.  Does the patch below fix the problem?

I also think internal-char-font should not blindly call the font
driver without checking that it isn't NULL first.

=== modified file 'lisp/descr-text.el'
--- lisp/descr-text.el	2012-08-20 11:12:16 +0000
+++ lisp/descr-text.el	2012-11-25 15:46:44 +0000
@@ -354,7 +354,8 @@ This function is semi-obsolete.  Use `ge
 ;; Return a string of CH with composition for padding on both sides.
 ;; It is displayed without overlapping with the left/right columns.
 (defsubst describe-char-padded-string (ch)
-  (if (internal-char-font nil ch)
+  (if (and (display-multi-font-p)
+	   (internal-char-font nil ch))
       (compose-string (string ch) 0 1 (format "\t%c\t" ch))
     (string ch)))
 

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

[Jan Djärv]

Hello.

Your patch fixes the problem.

	Jan D.

25 nov 2012 kl. 16:56 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 25 Nov 2012 13:18:28 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> ninestraycats@gmail.com,
>> 11964@debbugs.gnu.org
>> 
>> 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.
> 
> It is wrong to call internal-char-font on a non-GUI frame; for
> starters, that function might not be compiled in, e.g. if Emacs was
> configured --without-x.  All the other callers of that function are
> careful not to do that.  Does the patch below fix the problem?
> 
> I also think internal-char-font should not blindly call the font
> driver without checking that it isn't NULL first.
> 
> === modified file 'lisp/descr-text.el'
> --- lisp/descr-text.el	2012-08-20 11:12:16 +0000
> +++ lisp/descr-text.el	2012-11-25 15:46:44 +0000
> @@ -354,7 +354,8 @@ This function is semi-obsolete.  Use `ge
> ;; Return a string of CH with composition for padding on both sides.
> ;; It is displayed without overlapping with the left/right columns.
> (defsubst describe-char-padded-string (ch)
> -  (if (internal-char-font nil ch)
> +  (if (and (display-multi-font-p)
> +	   (internal-char-font nil ch))
>       (compose-string (string ch) 0 1 (format "\t%c\t" ch))
>     (string ch)))
> 

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

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sun, 25 Nov 2012 17:16:23 +0100
> Cc: cyd@gnu.org,
>  ninestraycats@gmail.com,
>  11964@debbugs.gnu.org
> 
> Your patch fixes the problem.

Thanks, installed on the emacs-24 branch.

Can this bug be closed now?  (I didn't track all its discussions.)

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

[Jan Djärv]

Hi.

It is closed.

	Jan D.

25 nov 2012 kl. 17:34 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sun, 25 Nov 2012 17:16:23 +0100
>> Cc: cyd@gnu.org,
>> ninestraycats@gmail.com,
>> 11964@debbugs.gnu.org
>> 
>> Your patch fixes the problem.
> 
> Thanks, installed on the emacs-24 branch.
> 
> Can this bug be closed now?  (I didn't track all its discussions.)

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> It is wrong to call internal-char-font on a non-GUI frame; for
> starters, that function might not be compiled in, e.g. if Emacs was
> configured --without-x.  All the other callers of that function are
> careful not to do that.  Does the patch below fix the problem?
>
> I also think internal-char-font should not blindly call the font
> driver without checking that it isn't NULL first.

Thanks for the patch.  But I'm not sure this is 100% fixed yet: calling
internal-char-font on a tty should not crash Emacs, since Lisp calls
should never cause a crash.  So I think internal-char-font should return
nil if the seleced frame is non-graphical.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,
>   ninestraycats@gmail.com,  11964@debbugs.gnu.org
> Date: Mon, 26 Nov 2012 11:55:32 +0800
> 
> Thanks for the patch.  But I'm not sure this is 100% fixed yet: calling
> internal-char-font on a tty should not crash Emacs, since Lisp calls
> should never cause a crash.  So I think internal-char-font should return
> nil if the seleced frame is non-graphical.

Done in revision 110962 on the emacs-24 branch.