GNU bug report logs -
#11964
describe-char causes a fatal error (abort trap: 6) in non-windowed mode
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11964 in the body.
You can then email your comments to 11964 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Tue, 17 Jul 2012 21:29:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dan Maftei <ninestraycats <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 17 Jul 2012 21:29:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Mon, 05 Nov 2012 14:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Dan Maftei <ninestraycats <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Mon, 05 Nov 2012 15:24:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Hello.
5 nov 2012 kl. 15:23 skrev Chong Yidong <cyd <at> gnu.org>:
> Dan Maftei <ninestraycats <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Mon, 05 Nov 2012 18:56:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 11964 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:
> Dan Maftei <ninestraycats <at> 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?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Fri, 23 Nov 2012 06:29:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv <jan.h.d <at> 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)?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Fri, 23 Nov 2012 07:10:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Hello.
23 nov 2012 kl. 07:26 skrev Chong Yidong <cyd <at> gnu.org>:
> Jan Djärv <jan.h.d <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Fri, 23 Nov 2012 09:30:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv <jan.h.d <at> 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.
Reply sent
to
Jan Djärv <jan.h.d <at> swipnet.se>:
You have taken responsibility.
(Sat, 24 Nov 2012 18:02:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dan Maftei <ninestraycats <at> gmail.com>:
bug acknowledged by developer.
(Sat, 24 Nov 2012 18:02:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 11964-done <at> debbugs.gnu.org (full text, mbox):
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 <at> swipnet.se>:
> Hello.
>
> 23 nov 2012 kl. 07:26 skrev Chong Yidong <cyd <at> gnu.org>:
>
>> Jan Djärv <jan.h.d <at> 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.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sat, 24 Nov 2012 18:21:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 11964 <at> debbugs.gnu.org (full text, mbox):
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 24 Nov 2012 18:59:54 +0100
> Cc: Dan Maftei <ninestraycats <at> gmail.com>, 11964-done <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 05:33:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Jan Djärv <jan.h.d <at> 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 <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 12:21:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Hello.
25 nov 2012 kl. 06:30 skrev Chong Yidong <cyd <at> gnu.org>:
> Jan Djärv <jan.h.d <at> 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 <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 15:59:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 11964 <at> debbugs.gnu.org (full text, mbox):
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sun, 25 Nov 2012 13:18:28 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> ninestraycats <at> gmail.com,
> 11964 <at> 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)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 16:19:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Hello.
Your patch fixes the problem.
Jan D.
25 nov 2012 kl. 16:56 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Sun, 25 Nov 2012 13:18:28 +0100
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> ninestraycats <at> gmail.com,
>> 11964 <at> 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)))
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 16:36:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 11964 <at> debbugs.gnu.org (full text, mbox):
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sun, 25 Nov 2012 17:16:23 +0100
> Cc: cyd <at> gnu.org,
> ninestraycats <at> gmail.com,
> 11964 <at> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Sun, 25 Nov 2012 17:20:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Hi.
It is closed.
Jan D.
25 nov 2012 kl. 17:34 skrev Eli Zaretskii <eliz <at> gnu.org>:
>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Sun, 25 Nov 2012 17:16:23 +0100
>> Cc: cyd <at> gnu.org,
>> ninestraycats <at> gmail.com,
>> 11964 <at> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Mon, 26 Nov 2012 03:58:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 11964 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11964; Package
emacs.
(Mon, 26 Nov 2012 17:51:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 11964 <at> debbugs.gnu.org (full text, mbox):
> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Jan Djärv <jan.h.d <at> swipnet.se>,
> ninestraycats <at> gmail.com, 11964 <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 25 Dec 2012 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 136 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.