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