* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
@ 2012-07-16 22:51 Dan Maftei
2012-11-05 14:23 ` Chong Yidong
0 siblings, 1 reply; 17+ messages in thread
From: Dan Maftei @ 2012-07-16 22:51 UTC (permalink / raw)
To: 11964
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-07-16 22:51 bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode Dan Maftei
@ 2012-11-05 14:23 ` Chong Yidong
2012-11-05 15:20 ` Jan Djärv
2012-11-05 18:52 ` Dan Maftei
0 siblings, 2 replies; 17+ messages in thread
From: Chong Yidong @ 2012-11-05 14:23 UTC (permalink / raw)
To: Dan Maftei; +Cc: 11964
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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-05 14:23 ` Chong Yidong
@ 2012-11-05 15:20 ` Jan Djärv
2012-11-23 6:26 ` Chong Yidong
2012-11-05 18:52 ` Dan Maftei
1 sibling, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2012-11-05 15:20 UTC (permalink / raw)
To: Chong Yidong; +Cc: Dan Maftei, 11964
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-05 14:23 ` Chong Yidong
2012-11-05 15:20 ` Jan Djärv
@ 2012-11-05 18:52 ` Dan Maftei
1 sibling, 0 replies; 17+ messages in thread
From: Dan Maftei @ 2012-11-05 18:52 UTC (permalink / raw)
To: Chong Yidong; +Cc: 11964
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-05 15:20 ` Jan Djärv
@ 2012-11-23 6:26 ` Chong Yidong
2012-11-23 7:07 ` Jan Djärv
0 siblings, 1 reply; 17+ messages in thread
From: Chong Yidong @ 2012-11-23 6:26 UTC (permalink / raw)
To: Jan Djärv; +Cc: Dan Maftei, 11964
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)?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-23 6:26 ` Chong Yidong
@ 2012-11-23 7:07 ` Jan Djärv
2012-11-23 9:28 ` Chong Yidong
2012-11-24 17:59 ` Jan Djärv
0 siblings, 2 replies; 17+ messages in thread
From: Jan Djärv @ 2012-11-23 7:07 UTC (permalink / raw)
To: Chong Yidong; +Cc: Dan Maftei, 11964
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-23 7:07 ` Jan Djärv
@ 2012-11-23 9:28 ` Chong Yidong
2012-11-24 17:59 ` Jan Djärv
1 sibling, 0 replies; 17+ messages in thread
From: Chong Yidong @ 2012-11-23 9:28 UTC (permalink / raw)
To: Jan Djärv; +Cc: Dan Maftei, 11964
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-23 7:07 ` Jan Djärv
2012-11-23 9:28 ` Chong Yidong
@ 2012-11-24 17:59 ` Jan Djärv
2012-11-24 18:19 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2012-11-24 17:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: Dan Maftei, 11964-done
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.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-24 17:59 ` Jan Djärv
@ 2012-11-24 18:19 ` Eli Zaretskii
2012-11-25 5:30 ` Chong Yidong
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2012-11-24 18:19 UTC (permalink / raw)
To: Jan Djärv; +Cc: ninestraycats, 11964
> 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?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-24 18:19 ` Eli Zaretskii
@ 2012-11-25 5:30 ` Chong Yidong
2012-11-25 12:18 ` Jan Djärv
0 siblings, 1 reply; 17+ messages in thread
From: Chong Yidong @ 2012-11-25 5:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ninestraycats, 11964
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 5:30 ` Chong Yidong
@ 2012-11-25 12:18 ` Jan Djärv
2012-11-25 15:56 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2012-11-25 12:18 UTC (permalink / raw)
To: Chong Yidong; +Cc: ninestraycats, 11964
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)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 12:18 ` Jan Djärv
@ 2012-11-25 15:56 ` Eli Zaretskii
2012-11-25 16:16 ` Jan Djärv
2012-11-26 3:55 ` Chong Yidong
0 siblings, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2012-11-25 15:56 UTC (permalink / raw)
To: Jan Djärv; +Cc: ninestraycats, 11964, cyd
> 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)))
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 15:56 ` Eli Zaretskii
@ 2012-11-25 16:16 ` Jan Djärv
2012-11-25 16:34 ` Eli Zaretskii
2012-11-26 3:55 ` Chong Yidong
1 sibling, 1 reply; 17+ messages in thread
From: Jan Djärv @ 2012-11-25 16:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ninestraycats, 11964, cyd
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)))
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 16:16 ` Jan Djärv
@ 2012-11-25 16:34 ` Eli Zaretskii
2012-11-25 17:17 ` Jan Djärv
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2012-11-25 16:34 UTC (permalink / raw)
To: Jan Djärv; +Cc: ninestraycats, 11964, cyd
> 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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 16:34 ` Eli Zaretskii
@ 2012-11-25 17:17 ` Jan Djärv
0 siblings, 0 replies; 17+ messages in thread
From: Jan Djärv @ 2012-11-25 17:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ninestraycats, 11964, cyd
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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-25 15:56 ` Eli Zaretskii
2012-11-25 16:16 ` Jan Djärv
@ 2012-11-26 3:55 ` Chong Yidong
2012-11-26 17:47 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Chong Yidong @ 2012-11-26 3:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ninestraycats, 11964
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode
2012-11-26 3:55 ` Chong Yidong
@ 2012-11-26 17:47 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2012-11-26 17:47 UTC (permalink / raw)
To: Chong Yidong; +Cc: ninestraycats, 11964
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-11-26 17:47 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-16 22:51 bug#11964: describe-char causes a fatal error (abort trap: 6) in non-windowed mode Dan Maftei
2012-11-05 14:23 ` Chong Yidong
2012-11-05 15:20 ` Jan Djärv
2012-11-23 6:26 ` Chong Yidong
2012-11-23 7:07 ` Jan Djärv
2012-11-23 9:28 ` Chong Yidong
2012-11-24 17:59 ` Jan Djärv
2012-11-24 18:19 ` Eli Zaretskii
2012-11-25 5:30 ` Chong Yidong
2012-11-25 12:18 ` Jan Djärv
2012-11-25 15:56 ` Eli Zaretskii
2012-11-25 16:16 ` Jan Djärv
2012-11-25 16:34 ` Eli Zaretskii
2012-11-25 17:17 ` Jan Djärv
2012-11-26 3:55 ` Chong Yidong
2012-11-26 17:47 ` Eli Zaretskii
2012-11-05 18:52 ` Dan Maftei
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).