* Emacs 23.1.93 pretest @ 2010-02-27 3:40 Chong Yidong 2010-02-27 9:05 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Chong Yidong @ 2010-02-27 3:40 UTC (permalink / raw) To: emacs-devel Emacs pretest 23.1.93 is now available for download via FTP, at the following location: ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.93.tar.gz The xdelta against the Emacs 23.1.92 pretest is here: ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.92-23.1.93.xdelta This is the fourth pretest for what will be the Emacs 23.2 release. Developers: as explained in a previous email, in a few days we will cut the 23.2 branch and open the trunk for Emacs 24 development. Only regression bugfixes and documentation changes will be accepted into the branch. So consider this the very last call for non-regression fixes: if there is one that you would like to make, please discuss on emacs-devel now. Pretesters: please send me an email reporting success or failure on your build platform. Report bugs via M-x report-emacs-bugs, or email emacs-pretest-bug@gnu.org. For questions, email emacs-devel@gnu.org. Thanks. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 3:40 Emacs 23.1.93 pretest Chong Yidong @ 2010-02-27 9:05 ` Eli Zaretskii 2010-02-27 10:21 ` Eli Zaretskii 2010-03-02 15:42 ` Drew Adams 2010-03-04 14:36 ` bug#5679: " Sergei Organov 2 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 9:05 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Fri, 26 Feb 2010 22:40:05 -0500 > > Emacs pretest 23.1.93 is now available for download via FTP, at the > following location: > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.93.tar.gz > > The xdelta against the Emacs 23.1.92 pretest is here: > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.92-23.1.93.xdelta > > This is the fourth pretest for what will be the Emacs 23.2 release. It crashes for me on MS-Windows, while loading my desktop file. I'm trying to debug this. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 9:05 ` Eli Zaretskii @ 2010-02-27 10:21 ` Eli Zaretskii 2010-02-27 11:28 ` Juanma Barranquero 2010-02-27 11:57 ` Eli Zaretskii 0 siblings, 2 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 10:21 UTC (permalink / raw) To: cyd, emacs-devel > Date: Sat, 27 Feb 2010 11:05:01 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > From: Chong Yidong <cyd@stupidchicken.com> > > Date: Fri, 26 Feb 2010 22:40:05 -0500 > > > > Emacs pretest 23.1.93 is now available for download via FTP, at the > > following location: > > > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.93.tar.gz > > > > The xdelta against the Emacs 23.1.92 pretest is here: > > > > ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.92-23.1.93.xdelta > > > > This is the fourth pretest for what will be the Emacs 23.2 release. > > It crashes for me on MS-Windows, while loading my desktop file. I'm > trying to debug this. The problem is this line from my desktop file: (setq regexp-search-ring '("[^]$" "\\bmac" "\\`n" "\\`m" "\\\\`ma" "\\. [^ ]" "^`" "^\\\\" "/[A-Za-z] " "/. ." " $" "/.*ş" "/.*\naba/f" "^" "/.*H" "[[^ ]*[^]] ")) There's a Latin-2 character `ş' there. If I delete the "/.*ş" part of the regexp-search-ring, Emacs starts correctly. Emacs 23.1.92 loads the same desktop file without any trouble, so this is a regression. From this and other symptoms (see below), it looks like the emacs-mule decoding is broken in this pretest. For example, visiting the offending desktop file with the Latin-2 character in place causes many characters following this Latin-2 character to disappear from display, as if they didn't exist in the file. Killing the buffer and visiting the file again magically restores the characters that disappeared. I cannot produce a GDB backtrace: I could not find a way of reproducing the crash under GDB. All I get is a weird wrong-type-argument error: Debugger entered--Lisp error: (wrong-type-argument symbolp (quote ((tab-width . 8) (buffer-file-coding-system . iso-latin-1-unix) (case-fold-search . t)))) But I think this is because the failure to decode the desktop file correctly causes Emacs to try evaluating a butchered expression. FWIW, here's the backtrace of the crash produced by Dr MinGW, a GIT debugger that pops up when Emacs crashes. Note that it crashes in decode_coding_emacs_mule, yet another sign that this is the culprit. emacs.exe caused an Access Violation at location 0112b000 in module emacs.exe Reading from location 03194000. Registers: eax=03194000 ebx=00000000 ecx=03194000 edx=00002c50 esi=00000000 edi=0081572c eip=0112b000 esp=0080a550 ebp=0080a5b8 iopl=0 nv up ei ng nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000293 Call stack: 0112B000 emacs.exe:0112B000 decode_coding_emacs_mule coding.c:2497 ... c = byte_after_cr, byte_after_cr = -1; else > ONE_MORE_BYTE (c); if (c < 0 || c == 0x80) ... 01134F4F emacs.exe:01134F4F decode_coding coding.c:7158 ... coding->charbuf_used = carryover; (*(coding->decoder)) (coding); > coding_set_destination (coding); carryover = produce_chars (coding, translation_table, 0); if (coding->annotated) ... 01138823 emacs.exe:01138823 decode_coding_gap coding.c:7666 ... current_buffer->text->inhibit_shrinking = 1; decode_coding (coding); > current_buffer->text->inhibit_shrinking = 0; attrs = CODING_ID_ATTRS (coding->id); ... 0104E7B8 emacs.exe:0104E7B8 Finsert_file_contents fileio.c:4083 ... decode_coding_gap (&coding, inserted, inserted); inserted = coding.produced_char; > coding_system = CODING_ID_NAME (coding.id); } else if (inserted > 0) ... 0100C5AD emacs.exe:0100C5AD Ffuncall eval.c:3038 ... goto done; case 5: > val = (*XSUBR (fun)->function) (internal_args[0], internal_args[1], internal_args[2], internal_args[3], internal_args[4]); ... 0111E0F6 emacs.exe:0111E0F6 Fbyte_code bytecode.c:679 ... } #endif > TOP = Ffuncall (op + 1, &TOP); AFTER_POTENTIAL_GC (); break; ... 0100C012 emacs.exe:0100C012 funcall_lambda eval.c:3216 ... } > return unbind_to (count, val); } ... 0100C3F6 emacs.exe:0100C3F6 Ffuncall eval.c:3093 ... done: CHECK_CONS_LIST (); > lisp_eval_depth--; if (backtrace.debug_on_exit) val = call_debugger (Fcons (Qexit, Fcons (val, Qnil))); ... 0100C78E emacs.exe:0100C78E call4 eval.c:2880 ... RETURN_UNGCPRO (Ffuncall (5, &fn)); #endif /* not NO_ARG_ARRAY */ > } /* Call function fn with 5 arguments arg1, arg2, arg3, arg4, arg5 */ ... 0107AC20 emacs.exe:0107AC20 Fload lread.c:1225 ... NILP (noerror) ? Qnil : Qt, (NILP (nomessage) || force_load_messages) ? Qnil : Qt); > return unbind_to (count, val); } } ... 0100C5AD emacs.exe:0100C5AD Ffuncall eval.c:3038 ... goto done; case 5: > val = (*XSUBR (fun)->function) (internal_args[0], internal_args[1], internal_args[2], internal_args[3], internal_args[4]); ... 0111E0F6 emacs.exe:0111E0F6 Fbyte_code bytecode.c:679 ... } #endif > TOP = Ffuncall (op + 1, &TOP); AFTER_POTENTIAL_GC (); break; ... 0100C012 emacs.exe:0100C012 funcall_lambda eval.c:3216 ... } > return unbind_to (count, val); } ... 0100C3F6 emacs.exe:0100C3F6 Ffuncall eval.c:3093 ... done: CHECK_CONS_LIST (); > lisp_eval_depth--; if (backtrace.debug_on_exit) val = call_debugger (Fcons (Qexit, Fcons (val, Qnil))); ... 0111E0F6 emacs.exe:0111E0F6 Fbyte_code bytecode.c:679 ... } #endif > TOP = Ffuncall (op + 1, &TOP); AFTER_POTENTIAL_GC (); break; ... 0100C012 emacs.exe:0100C012 funcall_lambda eval.c:3216 ... } > return unbind_to (count, val); } ... 0100C3F6 emacs.exe:0100C3F6 Ffuncall eval.c:3093 ... done: CHECK_CONS_LIST (); > lisp_eval_depth--; if (backtrace.debug_on_exit) val = call_debugger (Fcons (Qexit, Fcons (val, Qnil))); ... 0100CB8B emacs.exe:0100CB8B run_hook_with_args eval.c:2683 ... { args[0] = XCAR (val); > ret = Ffuncall (nargs, args); } } ... 0100CD1C emacs.exe:0100CD1C Frun_hooks eval.c:2534 ... register int i; > for (i = 0; i < nargs; i++) { hook[0] = args[i]; ... 0100C6B4 emacs.exe:0100C6B4 Ffuncall eval.c:3005 ... if (XSUBR (fun)->max_args == MANY) { > val = (*XSUBR (fun)->function) (numargs, args + 1); goto done; } ... 0111E0F6 emacs.exe:0111E0F6 Fbyte_code bytecode.c:679 ... } #endif > TOP = Ffuncall (op + 1, &TOP); AFTER_POTENTIAL_GC (); break; ... 0100C012 emacs.exe:0100C012 funcall_lambda eval.c:3216 ... } > return unbind_to (count, val); } ... 0100C3F6 emacs.exe:0100C3F6 Ffuncall eval.c:3093 ... done: CHECK_CONS_LIST (); > lisp_eval_depth--; if (backtrace.debug_on_exit) val = call_debugger (Fcons (Qexit, Fcons (val, Qnil))); ... 0111E0F6 emacs.exe:0111E0F6 Fbyte_code bytecode.c:679 ... } #endif > TOP = Ffuncall (op + 1, &TOP); AFTER_POTENTIAL_GC (); break; ... 0100C012 emacs.exe:0100C012 funcall_lambda eval.c:3216 ... } > return unbind_to (count, val); } ... 0100D1AD emacs.exe:0100D1AD apply_lambda eval.c:3135 ... } backtrace_list->evalargs = 0; > tem = funcall_lambda (fun, XINT (numargs), arg_vector); /* Do the debug-on-exit now, while arg_vector still exists. */ ... 0100B906 emacs.exe:0100B906 Feval eval.c:2413 ... CHECK_CONS_LIST (); > lisp_eval_depth--; if (backtrace.debug_on_exit) val = call_debugger (Fcons (Qexit, Fcons (val, Qnil))); ... 01053927 emacs.exe:01053927 top_level_2 keyboard.c:1370 ... { return Feval (Vtop_level); > } Lisp_Object ... 0100A16A emacs.exe:0100A16A internal_condition_case eval.c:1491 ... val = (*bfun) (); > catchlist = c.next; handlerlist = h.next; return val; ... 01053959 emacs.exe:01053959 top_level_1 keyboard.c:1382 ... else message ("Bare Emacs (standard Lisp code not loaded)"); > return Qnil; } ... 0100A09F emacs.exe:0100A09F internal_catch eval.c:1226 ... /* Call FUNC. */ if (! _setjmp (c.jmp)) > c.val = (*func) (arg); /* Throw works by a longjmp that comes right here. */ ... 010536F9 emacs.exe:010536F9 command_loop keyboard.c:1339 ... any_kboard_state (); #endif > internal_catch (Qtop_level, command_loop_2, Qnil); executing_kbd_macro = Qnil; ... 010537B0 emacs.exe:010537B0 recursive_edit_1 keyboard.c:955 ... val = command_loop (); > if (EQ (val, Qt)) Fsignal (Qquit, Qnil); /* Handle throw from read_minibuf when using minibuffer ... 010538D1 emacs.exe:010538D1 Frecursive_edit keyboard.c:1017 ... recursive_edit_1 (); > return unbind_to (count, Qnil); } ... 01002E2F emacs.exe:01002E2F main emacs.c:1836 ... /* NOTREACHED */ return 0; > } /* Sort the args so we can find the most important ones ... 0100124B emacs.exe:0100124B 01001298 emacs.exe:01001298 7C816D4F kernel32.dll:7C816D4F RegisterWaitForInputIdle ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 10:21 ` Eli Zaretskii @ 2010-02-27 11:28 ` Juanma Barranquero 2010-02-27 12:11 ` Juanma Barranquero 2010-02-27 11:57 ` Eli Zaretskii 1 sibling, 1 reply; 55+ messages in thread From: Juanma Barranquero @ 2010-02-27 11:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, emacs-devel 2010/2/27 Eli Zaretskii <eliz@gnu.org>: > I cannot produce a GDB backtrace: I could not find a way of > reproducing the crash under GDB. All I get is a weird > wrong-type-argument error: This is an optimized build, but I can get a crash by doing C-h h. I get this backtrace: Breakpoint 1, w32_abort () at w32fns.c:7345 7345 button = MessageBox (NULL, (gdb) bt #0 w32_abort () at w32fns.c:7345 #1 0x0101ef48 in die (msg=0x14c453c "assertion failed: CONSP((rest))", file=0x14c3bb8 "w32uniscribe.c", line=676) at alloc.c:6259 #2 0x01228124 in uniscribe_check_otf (font=0x88ca60, otf_spec=20161510) at w32uniscribe.c:676 #3 0x012241cb in font_matches_spec (logical_font=0x88ca60, physical_font=0x88c878, font_type=4, lParam=8965156) at w32font.c:1313 #4 add_font_entity_to_list (logical_font=0x88ca60, physical_font=0x88c878, font_type=4, lParam=8965156) at w32font.c:1428 #5 0x77561f91 in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #6 0x0088ca60 in ?? () #7 0x0088c878 in ?? () #8 0x00000004 in ?? () #9 0x0088cc24 in ?? () #10 0x00cb7668 in ?? () #11 0x00cb7668 in ?? () #12 0x00000001 in ?? () #13 0x00000024 in ?? () #14 0x0000001a in ?? () #15 0x0000000a in ?? () #16 0x00000004 in ?? () #17 0x00000000 in ?? () I'll do an unoptimized build and report back. Juanma ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 11:28 ` Juanma Barranquero @ 2010-02-27 12:11 ` Juanma Barranquero 2010-02-27 13:15 ` Eli Zaretskii 0 siblings, 1 reply; 55+ messages in thread From: Juanma Barranquero @ 2010-02-27 12:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, emacs-devel On Sat, Feb 27, 2010 at 12:28, Juanma Barranquero <lekktu@gmail.com> wrote: > I'll do an unoptimized build and report back. Same result. Transcript follows. Juanma w32uniscribe.c:676: Emacs fatal error: assertion failed: CONSP((rest)) Breakpoint 1, w32_abort () at w32fns.c:7345 7345 button = MessageBox (NULL, (gdb) bt #0 w32_abort () at w32fns.c:7345 #1 0x0104d987 in die (msg=0x1663908 "assertion failed: CONSP((rest))", file=0x1662008 "w32uniscribe.c", line=676) at alloc.c:6259 #2 0x01328ac7 in uniscribe_check_otf (font=0x88d630, otf_spec=21217310) at w32uniscribe.c:676 #3 0x01321769 in font_matches_spec (type=4, font=0x88d448, spec=48831493, backend=48927794, logfont=0x88d630) at w32font.c:1313 #4 0x01321a43 in add_font_entity_to_list (logical_font=0x88d630, physical_font=0x88d448, font_type=4, lParam=8968168) at w32font.c:1428 #5 0x77561f91 in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #6 0x0088d630 in ?? () #7 0x0088d448 in ?? () #8 0x00000004 in ?? () #9 0x0088d7e8 in ?? () #10 0x00978d18 in ?? () #11 0x00978d18 in ?? () #12 0x00000001 in ?? () #13 0x00000024 in ?? () #14 0x0000001a in ?? () #15 0x0000000a in ?? () #16 0x00000004 in ?? () #17 0x00000000 in ?? () (gdb) frame 2 #2 0x01328ac7 in uniscribe_check_otf (font=0x88d630, otf_spec=21217310) at w32uniscribe.c:676 676 lang = XCAR (rest); (gdb) p *font $1 = { lfHeight = 36, lfWidth = 19, lfEscapement = 0, lfOrientation = 0, lfWeight = 400, lfItalic = 0 '\000', lfUnderline = 0 '\000', lfStrikeOut = 0 '\000', lfCharSet = 0 '\000', lfOutPrecision = 3 '\003', lfClipPrecision = 2 '\002', lfQuality = 1 '\001', lfPitchAndFamily = 49 '1', lfFaceName = "Courier New\000xÖ\210\000)ö\020\001\000\000\000\000\001\000\000\000T\000\000" } (gdb) p otf_spec $2 = 21217310 (gdb) pr (mymr) (gdb) frame 3 #3 0x01321769 in font_matches_spec (type=4, font=0x88d448, spec=48831493, backend=48927794, logfont=0x88d630) at w32font.c:1313 1313 if (!uniscribe_check_otf (logfont, val)) (gdb) p *font $3 = { ntmTm = { tmHeight = 36, tmAscent = 26, tmDescent = 10, tmInternalLeading = 4, tmExternalLeading = 0, tmAveCharWidth = 19, tmMaxCharWidth = 24, tmWeight = 400, tmOverhang = 0, tmDigitizedAspectX = 96, tmDigitizedAspectY = 96, tmFirstChar = 30 '\036', tmLastChar = 255 '\377', tmDefaultChar = 31 '\037', tmBreakChar = 32 ' ', tmItalic = 0 '\000', tmUnderlined = 0 '\000', tmStruckOut = 0 '\000', tmPitchAndFamily = 54 '6', tmCharSet = 0 '\000', ntmFlags = 2359360, ntmSizeEM = 2048, ntmCellHeight = 2320, ntmAvgWidth = 1229 }, ntmFontSig = { fsUsb = {3758107391, 3221256259, 9, 0}, fsCsb = {1073742335, 4294901760} } } (gdb) p spec $4 = 48831493 (gdb) pr #<font-spec uniscribe outline Courier\ New mono iso10646-1 nil nil nil nil nil nil nil ((:otf mymr))> (gdb) p backend $5 = 48927794 (gdb) pr uniscribe (gdb) p logfont $6 = (LOGFONT *) 0x88d630 (gdb) p *logfont $7 = { lfHeight = 36, lfWidth = 19, lfEscapement = 0, lfOrientation = 0, lfWeight = 400, lfItalic = 0 '\000', lfUnderline = 0 '\000', lfStrikeOut = 0 '\000', lfCharSet = 0 '\000', lfOutPrecision = 3 '\003', lfClipPrecision = 2 '\002', lfQuality = 1 '\001', lfPitchAndFamily = 49 '1', lfFaceName = "Courier New\000xÖ\210\000)ö\020\001\000\000\000\000\001\000\000\000T\000\000" } (gdb) frame 4 #4 0x01321a43 in add_font_entity_to_list (logical_font=0x88d630, physical_font=0x88d448, font_type=4, lParam=8968168) at w32font.c:1428 1428 || !font_matches_spec (font_type, physical_font, (gdb) p *logical_font $8 = { elfLogFont = { lfHeight = 36, lfWidth = 19, lfEscapement = 0, lfOrientation = 0, lfWeight = 400, lfItalic = 0 '\000', lfUnderline = 0 '\000', lfStrikeOut = 0 '\000', lfCharSet = 0 '\000', lfOutPrecision = 3 '\003', lfClipPrecision = 2 '\002', lfQuality = 1 '\001', lfPitchAndFamily = 49 '1', lfFaceName = "Courier New\000xÖ\210\000)ö\020\001\000\000\000\000\001\000\000\000T\000\000" }, elfFullName = "Courier New\000\v\000\000\000b\000\000@\v", '\000' <repeats 25 times>, "•\000\000\000\000\000èÕ\210\000Ñ<'\003Ä\377\210", elfStyle = "Normal\000\000þ\377\377\377#;ÑwN;ÑwH@\000\000\000\000\000\000\000\000\000", elfScript = "Occidental\000\000\001\000\000\000$Ö\210\000;\f\000\000Ä\377\210\000\035\004Õw" } (gdb) p *physical_font $9 = { ntmTm = { tmHeight = 36, tmAscent = 26, tmDescent = 10, tmInternalLeading = 4, tmExternalLeading = 0, tmAveCharWidth = 19, tmMaxCharWidth = 24, tmWeight = 400, tmOverhang = 0, tmDigitizedAspectX = 96, tmDigitizedAspectY = 96, tmFirstChar = 30 '\036', tmLastChar = 255 '\377', tmDefaultChar = 31 '\037', tmBreakChar = 32 ' ', tmItalic = 0 '\000', tmUnderlined = 0 '\000', tmStruckOut = 0 '\000', tmPitchAndFamily = 54 '6', tmCharSet = 0 '\000', ntmFlags = 2359360, ntmSizeEM = 2048, ntmCellHeight = 2320, ntmAvgWidth = 1229 }, ntmFontSig = { fsUsb = {3758107391, 3221256259, 9, 0}, fsCsb = {1073742335, 4294901760} } } (gdb) p lParam $10 = 8968168 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 12:11 ` Juanma Barranquero @ 2010-02-27 13:15 ` Eli Zaretskii 2010-02-27 14:14 ` Eli Zaretskii ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 13:15 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cyd, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sat, 27 Feb 2010 13:11:45 +0100 > Cc: cyd@stupidchicken.com, emacs-devel@gnu.org > > w32uniscribe.c:676: Emacs fatal error: assertion failed: CONSP((rest)) > > Breakpoint 1, w32_abort () at w32fns.c:7345 > 7345 button = MessageBox (NULL, > (gdb) bt > #0 w32_abort () at w32fns.c:7345 > #1 0x0104d987 in die (msg=0x1663908 "assertion failed: > CONSP((rest))", file=0x1662008 "w32uniscribe.c", line=676) at > alloc.c:6259 > #2 0x01328ac7 in uniscribe_check_otf (font=0x88d630, > otf_spec=21217310) at w32uniscribe.c:676 > #3 0x01321769 in font_matches_spec (type=4, font=0x88d448, > spec=48831493, backend=48927794, logfont=0x88d630) at w32font.c:1313 > #4 0x01321a43 in add_font_entity_to_list (logical_font=0x88d630, > physical_font=0x88d448, font_type=4, lParam=8968168) at w32font.c:1428 > #5 0x77561f91 in GDI32!D3DKMTGetDeviceState () from > C:\Windows\syswow64\gdi32.dll > #6 0x0088d630 in ?? () > #7 0x0088d448 in ?? () > #8 0x00000004 in ?? () > #9 0x0088d7e8 in ?? () > #10 0x00978d18 in ?? () > #11 0x00978d18 in ?? () > #12 0x00000001 in ?? () > #13 0x00000024 in ?? () > #14 0x0000001a in ?? () > #15 0x0000000a in ?? () > #16 0x00000004 in ?? () > #17 0x00000000 in ?? () Thanks. I get a similar crash, but it isn't an assert violation. Program received signal SIGSEGV, Segmentation fault. 0x0118191d in uniscribe_check_otf (font=0x3, otf_spec=44922882) at w32uniscribe.c:684 684 features[1] = XCAR (rest); otf_spec is nil in my case: (gdb) p otf_spec $1 = 44922882 (gdb) xtype Lisp_Symbol (gdb) xsymbol $2 = (struct Lisp_Symbol *) 0x2ad7800 "nil" But then how come this defense in uniscribe_check_otf did not catch it? /* Check the spec is in the right format. */ if (!CONSP (otf_spec) || Flength (otf_spec) < 3) return 0; Some GC perhaps? See below for the full backtrace. Btw, what version of GDB are you using? It seems like it has some trouble showing a useful backtrace. My GDB is 7.0; if you have anything older, I recommend installing 7.0 from the MinGW site. Here's my backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0118191d in uniscribe_check_otf (font=0x3, otf_spec=44922882) at w32uniscribe.c:684 684 features[1] = XCAR (rest); (gdb) bt #0 0x0118191d in uniscribe_check_otf (font=0x3, otf_spec=44922882) at w32uniscribe.c:684 #1 0x0117d640 in add_font_entity_to_list (logical_font=0x82ca7c, physical_font=0x82c894, font_type=4, lParam=8571968) at w32font.c:1313 #2 0x77f3afb1 in GDI32!CreateFontA () from C:\WINDOWS\system32\gdi32.dll #3 0x77f345be in GetOutlineTextMetricsA () from C:\WINDOWS\system32\gdi32.dll #4 0x77f29f0b in GDI32!EnumFontFamiliesA () from C:\WINDOWS\system32\gdi32.dll #5 0x77f3ead3 in GDI32!EnumFontFamiliesExA () from C:\WINDOWS\system32\gdi32.dll #6 0x0117e5e3 in w32font_list_internal (frame=-8, font_spec=8806376, opentype_only=1) at w32font.c:760 #7 0x01180476 in uniscribe_list (frame=3, font_spec=45038597) at w32uniscribe.c:81 #8 0x010abe27 in font_list_entities (frame=50487301, spec=54573445) at font.c:2926 #9 0x010ac51c in font_find_for_lface (f=0x3003922, attrs=0x307f740, spec=45035776, c=-1) at font.c:3487 #10 0x010d6bb4 in fontset_find_font (fontset=50521093, c=4121, face=0x307f700, id=143, fallback=0) at fontset.c:636 #11 0x010d7387 in fontset_font (fontset=50523141, c=4121, face=0x307f700, id=143) at fontset.c:756 #12 0x010d7971 in font_for_char (face=0x307f700, c=4121, pos=49053658, object=3) at fontset.c:1049 #13 0x010a8fa1 in font_range (pos=417, limit=0x82cfbc, w=0x1019, face=0x307f700, string=44922882) at font.c:3997 #14 0x010e1206 in autocmp_chars (cft_element=417, charpos=416, bytepos=664, limit=432, win=0x3026c00, face=0x3, string=44922882) at composite.c:973 #15 0x010e2722 in composition_reseat_it (cmp_it=0x82deb8, charpos=416, bytepos=664, endpos=3131, w=0x3026c00, face=0x3, string=44922882) at composite.c:1147 #16 0x0101a59e in next_element_from_buffer (it=0x82db00) at xdisp.c:6532 #17 0x01018552 in get_next_display_element (it=0x82db00) at xdisp.c:5675 #18 0x0102397d in display_line (it=0x82db00) at xdisp.c:16570 #19 0x01024ccd in try_window (window=50490373, pos=..., check_margins=1) at xdisp.c:14028 #20 0x0102d5fd in redisplay_window (window=50490373, just_this_one_p=0) at xdisp.c:13651 #21 0x0102e937 in redisplay_window_0 (window=50490373) at xdisp.c:12283 #22 0x01009ed5 in internal_condition_case_1 ( bfun=0x102e90d <redisplay_window_0>, arg=50490373, handlers=44907174, hfun=0x101e27c <redisplay_window_error>) at eval.c:1538 #23 0x0101e049 in redisplay_windows (window=49053658) at xdisp.c:12262 #24 0x01030765 in redisplay_internal (preserve_echo_area=3) at xdisp.c:11834 #25 0x0105bed2 in read_char (commandflag=1, nmaps=3, maps=0x82fae0, prev_event=44922882, used_mouse_menu=0x82fb78, end_time=0x0) at keyboard.c:2727 #26 0x0105e332 in read_key_sequence (keybuf=0x82fcb0, bufsize=30, prompt=44922882, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #27 0x01060377 in command_loop_1 () at keyboard.c:1643 #28 0x0100a16a in internal_condition_case (bfun=0x10601cd <command_loop_1>, handlers=44979418, hfun=0x1059fa1 <cmd_error>) at eval.c:1490 #29 0x0105390a in command_loop_2 () at keyboard.c:1360 #30 0x0100a09f in internal_catch (tag=3, func=0x10538e7 <command_loop_2>, arg=44922882) at eval.c:1226 #31 0x01053717 in command_loop () at keyboard.c:1339 #32 0x010537b0 in recursive_edit_1 () at keyboard.c:954 #33 0x010538d1 in Frecursive_edit () at keyboard.c:1016 #34 0x01002e2f in main (argc=2, argv=0xa32770) at emacs.c:1833 (gdb) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 13:15 ` Eli Zaretskii @ 2010-02-27 14:14 ` Eli Zaretskii 2010-02-27 14:31 ` Andreas Schwab ` (3 subsequent siblings) 4 siblings, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 14:14 UTC (permalink / raw) To: lekktu, cyd, emacs-devel; +Cc: Kenichi Handa > Date: Sat, 27 Feb 2010 15:15:35 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: cyd@stupidchicken.com, emacs-devel@gnu.org > > Thanks. I get a similar crash, but it isn't an assert violation. > > Program received signal SIGSEGV, Segmentation fault. > 0x0118191d in uniscribe_check_otf (font=0x3, otf_spec=44922882) > at w32uniscribe.c:684 > 684 features[1] = XCAR (rest); > > otf_spec is nil in my case: > > (gdb) p otf_spec > $1 = 44922882 > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $2 = (struct Lisp_Symbol *) 0x2ad7800 > "nil" This sounds like a separate problem, though: it did not exist in revision 99563 (from yesterday's noon [UTC+2]), but exists in the current revision 99569 and in the pretest. By contrast, the problem with emacs-mule decoding exists in both revisions. > But then how come this defense in uniscribe_check_otf did not catch > it? > > /* Check the spec is in the right format. */ > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) > return 0; Answering my own question here: because otf_spec is a cons cell of the right length, but it looks not according to what uniscribe_check_otf expects: (gdb) p otf_spec $7 = 19320654 (gdb) xcons $8 = (struct Lisp_Cons *) 0x126cf48 { car = 0x2ec7fda, u = { cdr = 0x2ad7802, chain = 0x2ad7802 } } (gdb) p otf_spec $9 = 19320654 (gdb) xcdr $10 = 0x2ad7802 (gdb) xcdr $11 = 0x0 The change which causes it is this: === modified file 'lisp/international/fontset.el' --- lisp/international/fontset.el 2010-01-13 08:35:10 +0000 +++ lisp/international/fontset.el 2010-02-27 13:55:36 +0000 @@ -415,6 +415,9 @@ (sinhala ,(font-spec :registry "iso10646-1" :otf '(sinh nil (akhn)))) (malayalam ,(font-spec :registry "iso10646-1" :otf '(mlym nil (akhn)))) + (myanmar ,(font-spec :registry "iso10646-1" :otf '(mymr)) + ,(font-spec :registry "iso10646-1" :script 'myanmar)) + (lao ,(font-spec :registry "iso10646-1" :otf '(lao\ nil nil (mark))) ,(font-spec :registry "iso10646-1" :script 'lao) (nil . "MuleLao-1")) @@ -548,7 +551,6 @@ armenian syriac thaana - myanmar georgian cherokee canadian-aboriginal Perhaps Handa-san could take a look at this. The entry you added seems to violate the doc string of `font-spec', which says: `:otf' VALUE must be a list (SCRIPT-TAG LANGSYS-TAG GSUB [ GPOS ]) to specify required OpenType features. SCRIPT-TAG: OpenType script tag symbol (e.g. `deva'). LANGSYS-TAG: OpenType language system tag symbol, or nil for the default language system. GSUB: List of OpenType GSUB feature tag symbols, or nil if none required. GPOS: List of OpenType GPOS feature tag symbols, or nil if none required. Btw, the `:otf' spec does not seem to be documented in the ELisp manual. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 13:15 ` Eli Zaretskii 2010-02-27 14:14 ` Eli Zaretskii @ 2010-02-27 14:31 ` Andreas Schwab 2010-02-27 14:54 ` Eli Zaretskii 2010-02-27 15:22 ` Chong Yidong ` (2 subsequent siblings) 4 siblings, 1 reply; 55+ messages in thread From: Andreas Schwab @ 2010-02-27 14:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, cyd, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > But then how come this defense in uniscribe_check_otf did not catch > it? > > /* Check the spec is in the right format. */ > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) > return 0; Because `Flength (otf_spec) < 3' is bogus. It should be `XINT (Flength (otf_spec)) < 3'. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 14:31 ` Andreas Schwab @ 2010-02-27 14:54 ` Eli Zaretskii 2010-02-27 14:59 ` Lennart Borgman 0 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 14:54 UTC (permalink / raw) To: Andreas Schwab; +Cc: lekktu, cyd, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: Juanma Barranquero <lekktu@gmail.com>, cyd@stupidchicken.com, emacs-devel@gnu.org > Date: Sat, 27 Feb 2010 15:31:30 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > But then how come this defense in uniscribe_check_otf did not catch > > it? > > > > /* Check the spec is in the right format. */ > > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) > > return 0; > > Because `Flength (otf_spec) < 3' is bogus. It should be `XINT (Flength > (otf_spec)) < 3'. Right you are. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 14:54 ` Eli Zaretskii @ 2010-02-27 14:59 ` Lennart Borgman 2010-02-27 15:29 ` Eli Zaretskii 0 siblings, 1 reply; 55+ messages in thread From: Lennart Borgman @ 2010-02-27 14:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, cyd, Andreas Schwab, emacs-devel On Sat, Feb 27, 2010 at 3:54 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: Juanma Barranquero <lekktu@gmail.com>, cyd@stupidchicken.com, emacs-devel@gnu.org >> Date: Sat, 27 Feb 2010 15:31:30 +0100 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > But then how come this defense in uniscribe_check_otf did not catch >> > it? >> > >> > /* Check the spec is in the right format. */ >> > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) >> > return 0; >> >> Because `Flength (otf_spec) < 3' is bogus. It should be `XINT (Flength >> (otf_spec)) < 3'. > > Right you are. Are you checking in a change? Then could you perhaps tell me so I can build from the Launchpad mirror when the change has arrived there? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 14:59 ` Lennart Borgman @ 2010-02-27 15:29 ` Eli Zaretskii 0 siblings, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 15:29 UTC (permalink / raw) To: Lennart Borgman; +Cc: lekktu, cyd, schwab, emacs-devel > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Sat, 27 Feb 2010 15:59:07 +0100 > Cc: lekktu@gmail.com, cyd@stupidchicken.com, > Andreas Schwab <schwab@linux-m68k.org>, emacs-devel@gnu.org > > On Sat, Feb 27, 2010 at 3:54 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Andreas Schwab <schwab@linux-m68k.org> > >> Cc: Juanma Barranquero <lekktu@gmail.com>, cyd@stupidchicken.com, emacs-devel@gnu.org > >> Date: Sat, 27 Feb 2010 15:31:30 +0100 > >> > >> Eli Zaretskii <eliz@gnu.org> writes: > >> > >> > But then how come this defense in uniscribe_check_otf did not catch > >> > it? > >> > > >> > /* Check the spec is in the right format. */ > >> > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) > >> > return 0; > >> > >> Because `Flength (otf_spec) < 3' is bogus. It should be `XINT (Flength > >> (otf_spec)) < 3'. > > > > Right you are. > > > Are you checking in a change? Andreas already did. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 13:15 ` Eli Zaretskii 2010-02-27 14:14 ` Eli Zaretskii 2010-02-27 14:31 ` Andreas Schwab @ 2010-02-27 15:22 ` Chong Yidong 2010-02-27 18:58 ` Eli Zaretskii 2010-03-04 11:32 ` Kenichi Handa 2010-02-27 15:39 ` Juanma Barranquero 2010-02-27 19:41 ` Stefan Monnier 4 siblings, 2 replies; 55+ messages in thread From: Chong Yidong @ 2010-02-27 15:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > + (myanmar ,(font-spec :registry "iso10646-1" :otf '(mymr)) > + ,(font-spec :registry "iso10646-1" :script 'myanmar)) > + > > Perhaps Handa-san could take a look at this. The entry you added > seems to violate the doc string of `font-spec' I've checked in a fix for the :otf spec. > Btw, the `:otf' spec does not seem to be documented in the ELisp manual. I've just added it to display.texi. It's unfortunate that the pretest has an easily triggerable crash on Windows, but that's life. We should probably have another pretest soon, for the benefit of Windows testers---let's say Monday, March 8th, a bit more than a week from now. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 15:22 ` Chong Yidong @ 2010-02-27 18:58 ` Eli Zaretskii 2010-03-04 11:32 ` Kenichi Handa 1 sibling, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 18:58 UTC (permalink / raw) To: Chong Yidong; +Cc: lekktu, emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org > Date: Sat, 27 Feb 2010 10:22:56 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > > + (myanmar ,(font-spec :registry "iso10646-1" :otf '(mymr)) > > + ,(font-spec :registry "iso10646-1" :script 'myanmar)) > > + > > > > Perhaps Handa-san could take a look at this. The entry you added > > seems to violate the doc string of `font-spec' > > I've checked in a fix for the :otf spec. > > > Btw, the `:otf' spec does not seem to be documented in the ELisp manual. > > I've just added it to display.texi. Thanks. > It's unfortunate that the pretest has an easily triggerable crash on > Windows, but that's life. We should probably have another pretest soon, > for the benefit of Windows testers---let's say Monday, March 8th, a bit > more than a week from now. I would suggest to wait until the problem with decoding emacs-mule is fixed as well. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 15:22 ` Chong Yidong 2010-02-27 18:58 ` Eli Zaretskii @ 2010-03-04 11:32 ` Kenichi Handa 2010-03-04 12:35 ` Jason Rumney 1 sibling, 1 reply; 55+ messages in thread From: Kenichi Handa @ 2010-03-04 11:32 UTC (permalink / raw) To: Chong Yidong; +Cc: lekktu, eliz, emacs-devel In article <87tyt21z5b.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes: > Eli Zaretskii <eliz@gnu.org> writes: > > + (myanmar ,(font-spec :registry "iso10646-1" :otf '(mymr)) > > + ,(font-spec :registry "iso10646-1" :script 'myanmar)) > > + > > > > Perhaps Handa-san could take a look at this. The entry you added > > seems to violate the doc string of `font-spec' > I've checked in a fix for the :otf spec. Thank you, but I changed the spec to ":otf '(mymr nil nil))" because the only Burmese OTF font I know is from SIL and it doesn't contain "LangSys" "brm" nor "GPOS" "liga". Do you know any Burmese OTF fonts that matche with the spec "(mymr brm (liga mark))"? --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-04 11:32 ` Kenichi Handa @ 2010-03-04 12:35 ` Jason Rumney 0 siblings, 0 replies; 55+ messages in thread From: Jason Rumney @ 2010-03-04 12:35 UTC (permalink / raw) To: Kenichi Handa; +Cc: lekktu, Chong Yidong, eliz, emacs-devel Kenichi Handa <handa@m17n.org> writes: > Thank you, but I changed the spec to ":otf '(mymr nil nil))" > because the only Burmese OTF font I know is from SIL and it > doesn't contain "LangSys" "brm" nor "GPOS" "liga". There is another here: http://www.myanmarnlp.net.mm/opentype.htm But I don't know which LangSys and GPOS info it contains (I had it installed while developing the uniscribe backend on Windows, but not on my current GNU/Linux system. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 13:15 ` Eli Zaretskii ` (2 preceding siblings ...) 2010-02-27 15:22 ` Chong Yidong @ 2010-02-27 15:39 ` Juanma Barranquero 2010-02-27 19:41 ` Stefan Monnier 4 siblings, 0 replies; 55+ messages in thread From: Juanma Barranquero @ 2010-02-27 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, emacs-devel On Sat, Feb 27, 2010 at 14:15, Eli Zaretskii <eliz@gnu.org> wrote: > Btw, what version of GDB are you using? It seems like it has some > trouble showing a useful backtrace. My GDB is 7.0; if you have > anything older, I recommend installing 7.0 from the MinGW site. 7.0.1. Apparently, it does not work very well on 64-bit Windows 7. Juanma ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 13:15 ` Eli Zaretskii ` (3 preceding siblings ...) 2010-02-27 15:39 ` Juanma Barranquero @ 2010-02-27 19:41 ` Stefan Monnier 4 siblings, 0 replies; 55+ messages in thread From: Stefan Monnier @ 2010-02-27 19:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, cyd, emacs-devel > But then how come this defense in uniscribe_check_otf did not catch > it? > /* Check the spec is in the right format. */ > if (!CONSP (otf_spec) || Flength (otf_spec) < 3) > return 0; Once again I recommend that people compile with -DUSE_LISP_UNION_TYPE to catch such bugs. They're trivial to catch this way. Stefan ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 10:21 ` Eli Zaretskii 2010-02-27 11:28 ` Juanma Barranquero @ 2010-02-27 11:57 ` Eli Zaretskii 2010-02-27 19:03 ` Eli Zaretskii 1 sibling, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 11:57 UTC (permalink / raw) To: cyd, emacs-devel > Date: Sat, 27 Feb 2010 12:21:03 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: > > > Date: Sat, 27 Feb 2010 11:05:01 +0200 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: emacs-devel@gnu.org > > > For example, visiting the offending desktop file with the Latin-2 > character in place causes many characters following this Latin-2 > character to disappear from display, as if they didn't exist in the > file. In the MS-DOS port, it actually displays 15450 null characters instead of the real characters in the file. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 11:57 ` Eli Zaretskii @ 2010-02-27 19:03 ` Eli Zaretskii 2010-02-27 21:37 ` Chong Yidong 0 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 19:03 UTC (permalink / raw) To: cyd, emacs-devel > Date: Sat, 27 Feb 2010 13:57:36 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: > > > Date: Sat, 27 Feb 2010 12:21:03 +0200 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: > > > > > Date: Sat, 27 Feb 2010 11:05:01 +0200 > > > From: Eli Zaretskii <eliz@gnu.org> > > > Cc: emacs-devel@gnu.org > > > > > For example, visiting the offending desktop file with the Latin-2 > > character in place causes many characters following this Latin-2 > > character to disappear from display, as if they didn't exist in the > > file. > > In the MS-DOS port, it actually displays 15450 null characters instead > of the real characters in the file. "bzr bisect" points to this change as the reason for this bug: 2010-02-05 Chong Yidong <cyd@stupidchicken.com> * charset.c (load_charset_map_from_file): Allocate large charset_map_entries structure on the heap rather than the stack. (Bug#5526). The revisions before this change works correctly; all revisions after it fail as described above. Any ideas? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 19:03 ` Eli Zaretskii @ 2010-02-27 21:37 ` Chong Yidong 2010-02-27 22:22 ` Eli Zaretskii 0 siblings, 1 reply; 55+ messages in thread From: Chong Yidong @ 2010-02-27 21:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > "bzr bisect" points to this change as the reason for this bug: > > 2010-02-05 Chong Yidong <cyd@stupidchicken.com> > > * charset.c (load_charset_map_from_file): Allocate large > charset_map_entries structure on the heap rather than the stack. > (Bug#5526). > > The revisions before this change works correctly; all revisions after > it fail as described above. Hmm, this is strange. This change (actually the succeeding 2010-02-06 change to the same place) switches from using alloca to SAFE_ALLOCA (i.e. malloc, since the desired structure is large). But the only way I can see for this code to crash is if load_charset_map somehow makes a pointer into the allocated structure. But in that case, the old alloca case should have crashed too. If you remove the SAFE_FREE () calls, does that prevent the crash? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 21:37 ` Chong Yidong @ 2010-02-27 22:22 ` Eli Zaretskii 2010-02-28 1:25 ` Chong Yidong 2010-02-28 1:45 ` Chong Yidong 0 siblings, 2 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-27 22:22 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: emacs-devel@gnu.org > Date: Sat, 27 Feb 2010 16:37:47 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > > "bzr bisect" points to this change as the reason for this bug: > > > > 2010-02-05 Chong Yidong <cyd@stupidchicken.com> > > > > * charset.c (load_charset_map_from_file): Allocate large > > charset_map_entries structure on the heap rather than the stack. > > (Bug#5526). > > > > The revisions before this change works correctly; all revisions after > > it fail as described above. > > Hmm, this is strange. This change (actually the succeeding 2010-02-06 > change to the same place) switches from using alloca to SAFE_ALLOCA > (i.e. malloc, since the desired structure is large). But the only way I > can see for this code to crash is if load_charset_map somehow makes a > pointer into the allocated structure. But in that case, the old alloca > case should have crashed too. Yes, it _is_ weird. But the effect (see below) does look like we are freeing memory being used, or maybe overwriting some allocated buffer, or in some other way thrashing the arena. > If you remove the SAFE_FREE () calls, does that prevent the crash? There's only one SAFE_FREE call that I see; if I remove it, temacs crashes at loadup time, when it loads mule-conf. So I cannot even get as far as building Emacs. Btw, the problem I was trying to reproduce with "bzr bisect" was not a crash, but rather the fact that visiting an emacs-mule encoded desktop file with that Latin-2 character in it caused some 15K characters following the Latin-2 one be overwritten with nulls. The original crash somehow happens only when I click on an icon that invokes runemacs.exe, and I cannot reproduce it with the -Q switch. But since both issues seem to be related to decoding emacs-mule, and they both happen when visiting or loading the .emacs.desktop file, I'm assuming that these are different manifestations of the same problem. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 22:22 ` Eli Zaretskii @ 2010-02-28 1:25 ` Chong Yidong 2010-02-28 17:21 ` Eli Zaretskii 2010-02-28 1:45 ` Chong Yidong 1 sibling, 1 reply; 55+ messages in thread From: Chong Yidong @ 2010-02-28 1:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> If you remove the SAFE_FREE () calls, does that prevent the crash? > > There's only one SAFE_FREE call that I see; if I remove it, temacs > crashes at loadup time, when it loads mule-conf. So I cannot even get > as far as building Emacs. Sorry yeah---we need the SAFE_FREE call because otherwise the specpdl gets confused. How about if you replace the SAFE_ALLOC calls with xmalloc and omit the free() call at the end? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 1:25 ` Chong Yidong @ 2010-02-28 17:21 ` Eli Zaretskii 0 siblings, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-28 17:21 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sat, 27 Feb 2010 20:25:10 -0500 > Cc: emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > >> If you remove the SAFE_FREE () calls, does that prevent the crash? > > > > There's only one SAFE_FREE call that I see; if I remove it, temacs > > crashes at loadup time, when it loads mule-conf. So I cannot even get > > as far as building Emacs. > > Sorry yeah---we need the SAFE_FREE call because otherwise the specpdl > gets confused. > > How about if you replace the SAFE_ALLOC calls with xmalloc and omit the > free() call at the end? If I do that, temacs dies during loadup saying it's out of memory: "./oo-spd/i386/temacs.exe" -batch -l loadup dump Loading loadup.el (source)... Using load-path (../lisp) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Loading version.el (source)... Loading widget... Loading custom... Loading emacs-lisp/map-ynp... Loading cus-start... Loading international/mule... Loading international/mule-conf... Memory exhausted--use M-x save-some-buffers then exit and restart Emacs make: *** [oo-spd/i386/emacs.exe] Error -1 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-27 22:22 ` Eli Zaretskii 2010-02-28 1:25 ` Chong Yidong @ 2010-02-28 1:45 ` Chong Yidong 2010-02-28 10:46 ` Andreas Schwab 2010-02-28 17:15 ` Eli Zaretskii 1 sibling, 2 replies; 55+ messages in thread From: Chong Yidong @ 2010-02-28 1:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Hmm, this is strange. This change (actually the succeeding 2010-02-06 >> change to the same place) switches from using alloca to SAFE_ALLOCA >> (i.e. malloc, since the desired structure is large). But the only way I >> can see for this code to crash is if load_charset_map somehow makes a >> pointer into the allocated structure. But in that case, the old alloca >> case should have crashed too. > > Yes, it _is_ weird. But the effect (see below) does look like we are > freeing memory being used, or maybe overwriting some allocated buffer, > or in some other way thrashing the arena. Hmm, I think I may see the problem. Does this patch help? === modified file 'src/charset.c' *** src/charset.c 2010-02-06 13:23:33 +0000 --- src/charset.c 2010-02-28 01:45:17 +0000 *************** *** 530,535 **** --- 530,536 ---- large (larger than MAX_ALLOCA). */ SAFE_ALLOCA (head, struct charset_map_entries *, sizeof (struct charset_map_entries)); + bzero (head, sizeof (struct charset_map_entries)); entries = head; n_entries = 0; *************** *** 556,561 **** --- 557,563 ---- { SAFE_ALLOCA (entries->next, struct charset_map_entries *, sizeof (struct charset_map_entries)); + bzero (entries->next, sizeof (struct charset_map_entries)); entries = entries->next; } idx = n_entries % 0x10000; *************** *** 595,600 **** --- 597,603 ---- large (larger than MAX_ALLOCA). */ SAFE_ALLOCA (head, struct charset_map_entries *, sizeof (struct charset_map_entries)); + bzero (head, sizeof (struct charset_map_entries)); entries = head; n_entries = 0; *************** *** 631,636 **** --- 634,640 ---- { SAFE_ALLOCA (entries->next, struct charset_map_entries *, sizeof (struct charset_map_entries)); + bzero (entries->next, sizeof (struct charset_map_entries)); entries = entries->next; } idx = n_entries % 0x10000; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 1:45 ` Chong Yidong @ 2010-02-28 10:46 ` Andreas Schwab 2010-02-28 14:25 ` Chong Yidong 2010-02-28 17:15 ` Eli Zaretskii 1 sibling, 1 reply; 55+ messages in thread From: Andreas Schwab @ 2010-02-28 10:46 UTC (permalink / raw) To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Hmm, I think I may see the problem. Does this patch help? > > === modified file 'src/charset.c' > *** src/charset.c 2010-02-06 13:23:33 +0000 > --- src/charset.c 2010-02-28 01:45:17 +0000 > *************** > *** 530,535 **** > --- 530,536 ---- > large (larger than MAX_ALLOCA). */ > SAFE_ALLOCA (head, struct charset_map_entries *, > sizeof (struct charset_map_entries)); > + bzero (head, sizeof (struct charset_map_entries)); If that fixes anything then it was already broken before. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 10:46 ` Andreas Schwab @ 2010-02-28 14:25 ` Chong Yidong 2010-02-28 15:38 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Chong Yidong @ 2010-02-28 14:25 UTC (permalink / raw) To: Andreas Schwab; +Cc: Eli Zaretskii, emacs-devel Andreas Schwab <schwab@linux-m68k.org> writes: > If that fixes anything then it was already broken before. Yes, I think it was indeed broken before, and it's probably an accident that it worked before. The entries->next pointer needs to be initialized. (So we need the patch anyway, and I've checked it in.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 14:25 ` Chong Yidong @ 2010-02-28 15:38 ` Andreas Schwab 2010-02-28 17:32 ` Eli Zaretskii 2010-02-28 17:34 ` Eli Zaretskii 2 siblings, 0 replies; 55+ messages in thread From: Andreas Schwab @ 2010-02-28 15:38 UTC (permalink / raw) To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > The entries->next pointer needs to be initialized. Does it? AFAICS it is only used when the current table is full, in which case it will point to the next table anyway. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 14:25 ` Chong Yidong 2010-02-28 15:38 ` Andreas Schwab @ 2010-02-28 17:32 ` Eli Zaretskii 2010-02-28 19:31 ` Eli Zaretskii 2010-02-28 17:34 ` Eli Zaretskii 2 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-28 17:32 UTC (permalink / raw) To: Chong Yidong; +Cc: schwab, emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sun, 28 Feb 2010 09:25:04 -0500 > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > Andreas Schwab <schwab@linux-m68k.org> writes: > > > If that fixes anything then it was already broken before. > > Yes, I think it was indeed broken before, and it's probably an accident > that it worked before. The entries->next pointer needs to be > initialized. (So we need the patch anyway, and I've checked it in.) Well, unfortunately, it doesn't seem to solve the problem. And I agree with Andreas: if this were the reason, Emacs would have needed an unreasonable amount of luck to work before this change. I don't think the stack is zeroed out on Windows; I'm _positive_ it does not get zeroed out in the MSDOS build (just checked in the DJGPP library sources to be sure). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 17:32 ` Eli Zaretskii @ 2010-02-28 19:31 ` Eli Zaretskii 2010-03-02 18:15 ` Eli Zaretskii 0 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-28 19:31 UTC (permalink / raw) To: cyd, emacs-devel > Date: Sun, 28 Feb 2010 19:32:42 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: schwab@linux-m68k.org, emacs-devel@gnu.org > > Well, unfortunately, it doesn't seem to solve the problem. I made the following experiment: . restore the calls to alloca -- the bug goes away . now add an xmalloc call to allocate a `struct charset_map_entries' right before alloca and an xfree call to free that memory after the call to load_charset_map, without doing anything with the allocated buffer in between the calls to xmalloc and to xfree -- the bug is back! So I think the change in charset.c itself did not cause the bug, it just exposed a bug elsewhere, because it reshuffles the heap. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 19:31 ` Eli Zaretskii @ 2010-03-02 18:15 ` Eli Zaretskii 2010-03-02 19:53 ` Chong Yidong 0 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-03-02 18:15 UTC (permalink / raw) To: cyd, emacs-devel > Date: Sun, 28 Feb 2010 21:31:21 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: > > So I think the change in charset.c itself did not cause the bug, it > just exposed a bug elsewhere, because it reshuffles the heap. Actually, it turns out it's not ``reshuffling the heap'' that triggers the bug, but rather the fact that when we call xmalloc, Emacs might relocate buffer text. IOW, I found the reason for the bug. One of the callers of load_charset_map_from_file maintains pointers into buffer text, so when that gets relocated, ... you get the idea. The first naive attempt to solve it was unsuccessful, so there's probably something else at work here. Hmm... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-02 18:15 ` Eli Zaretskii @ 2010-03-02 19:53 ` Chong Yidong 2010-03-02 20:53 ` Eli Zaretskii 0 siblings, 1 reply; 55+ messages in thread From: Chong Yidong @ 2010-03-02 19:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Actually, it turns out it's not ``reshuffling the heap'' that triggers > the bug, but rather the fact that when we call xmalloc, Emacs might > relocate buffer text. > > IOW, I found the reason for the bug. One of the callers of > load_charset_map_from_file maintains pointers into buffer text, so > when that gets relocated, ... you get the idea. Could you point out where this happens? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-02 19:53 ` Chong Yidong @ 2010-03-02 20:53 ` Eli Zaretskii 2010-03-04 11:24 ` Kenichi Handa 0 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-03-02 20:53 UTC (permalink / raw) To: Chong Yidong; +Cc: Kenichi Handa, emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: emacs-devel@gnu.org > Date: Tue, 02 Mar 2010 14:53:51 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Actually, it turns out it's not ``reshuffling the heap'' that triggers > > the bug, but rather the fact that when we call xmalloc, Emacs might > > relocate buffer text. > > > > IOW, I found the reason for the bug. One of the callers of > > load_charset_map_from_file maintains pointers into buffer text, so > > when that gets relocated, ... you get the idea. > > Could you point out where this happens? Yes, I can, now that I know that myself ;-) The problem was in two places: in emacs_mule_char and in decode_coding_emacs_mule (which calls emacs_mule_char). emacs_mule_char called DECODE_CHAR, which could result in a call to decode_char, which could call load_charset_map_from_file (through load_charset). Both emacs_mule_char and decode_coding_emacs_mule walk through buffer text with pointers, and those need to be fixed-up after the call to load_charset_map_from_file. I replaced the call to DECODE_CHAR with CODING_DECODE_CHAR, which wraps DECODE_CHAR with code that fixes up the pointers to buffer text if a charset map was loaded by DECODE_CHAR. decode_coding_emacs_mule needed a similar fixup for its own pointers to buffer text. This is now fixed in the repository. I think this fixes the original problem; at least my .emacs.desktop file with a Latin-2 character now loads correctly, both in the MS-Windows build and in the MS-DOS build. Perhaps Handa-san could look at the two other callers of DECODE_CHAR in coding.c, and see if they, too, need to be replaced with CODING_DECODE_CHAR. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-02 20:53 ` Eli Zaretskii @ 2010-03-04 11:24 ` Kenichi Handa 0 siblings, 0 replies; 55+ messages in thread From: Kenichi Handa @ 2010-03-04 11:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, emacs-devel In article <83zl2q30pa.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > The problem was in two places: in emacs_mule_char and in > decode_coding_emacs_mule (which calls emacs_mule_char). > emacs_mule_char called DECODE_CHAR, which could result in a call to > decode_char, which could call load_charset_map_from_file (through > load_charset). Both emacs_mule_char and decode_coding_emacs_mule walk > through buffer text with pointers, and those need to be fixed-up after > the call to load_charset_map_from_file. > I replaced the call to DECODE_CHAR with CODING_DECODE_CHAR, which > wraps DECODE_CHAR with code that fixes up the pointers to buffer text > if a charset map was loaded by DECODE_CHAR. decode_coding_emacs_mule > needed a similar fixup for its own pointers to buffer text. > This is now fixed in the repository. I think this fixes the original > problem; at least my .emacs.desktop file with a Latin-2 character now > loads correctly, both in the MS-Windows build and in the MS-DOS build. Thank you for fixing it. > Perhaps Handa-san could look at the two other callers of DECODE_CHAR > in coding.c, and see if they, too, need to be replaced with > CODING_DECODE_CHAR. Two other callers of DECODE_CHAR Fdecode_sjis_char and Fdecode_big5_char, and they are ok. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 14:25 ` Chong Yidong 2010-02-28 15:38 ` Andreas Schwab 2010-02-28 17:32 ` Eli Zaretskii @ 2010-02-28 17:34 ` Eli Zaretskii 2010-02-28 21:34 ` Chong Yidong 2 siblings, 1 reply; 55+ messages in thread From: Eli Zaretskii @ 2010-02-28 17:34 UTC (permalink / raw) To: Chong Yidong; +Cc: schwab, emacs-devel Could this be due to some missing GCPRO? Can one of the functions called by load_charset_map GC? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 17:34 ` Eli Zaretskii @ 2010-02-28 21:34 ` Chong Yidong 0 siblings, 0 replies; 55+ messages in thread From: Chong Yidong @ 2010-02-28 21:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: schwab, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Could this be due to some missing GCPRO? Can one of the functions > called by load_charset_map GC? AFAIK load_charset_map does not evaluate anything, but you can check by binding inhibit_garbage_collection around the call to load_charset_map and checking if the problem persists. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-02-28 1:45 ` Chong Yidong 2010-02-28 10:46 ` Andreas Schwab @ 2010-02-28 17:15 ` Eli Zaretskii 1 sibling, 0 replies; 55+ messages in thread From: Eli Zaretskii @ 2010-02-28 17:15 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: emacs-devel@gnu.org > Date: Sat, 27 Feb 2010 20:45:45 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> Hmm, this is strange. This change (actually the succeeding 2010-02-06 > >> change to the same place) switches from using alloca to SAFE_ALLOCA > >> (i.e. malloc, since the desired structure is large). But the only way I > >> can see for this code to crash is if load_charset_map somehow makes a > >> pointer into the allocated structure. But in that case, the old alloca > >> case should have crashed too. > > > > Yes, it _is_ weird. But the effect (see below) does look like we are > > freeing memory being used, or maybe overwriting some allocated buffer, > > or in some other way thrashing the arena. > > Hmm, I think I may see the problem. Does this patch help? No, it doesn't :-( ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: Emacs 23.1.93 pretest 2010-02-27 3:40 Emacs 23.1.93 pretest Chong Yidong 2010-02-27 9:05 ` Eli Zaretskii @ 2010-03-02 15:42 ` Drew Adams 2010-03-02 16:02 ` Chong Yidong 2010-03-04 14:36 ` bug#5679: " Sergei Organov 2 siblings, 1 reply; 55+ messages in thread From: Drew Adams @ 2010-03-02 15:42 UTC (permalink / raw) To: 'Chong Yidong', emacs-devel > Originally, I planned to make the release branch and switch > the trunk to Emacs 24 development on Monday... > let's postphone the branching, and see where we stand in > about a week. >> Emacs pretest 23.1.93 is now available for download via >> FTP, at the following location: >> ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.93.tar.gz How's feedback from Windows users working out for ya (and I don't mean just build reports)? Gettin' any? There's no 23.1.93 at http://alpha.gnu.org/gnu/emacs/pretest/windows/, even though that's the advertised purpose of this GNU directory. The last post there is 23.1.91. (And no 23.1.93 binary on Lennart's site.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-02 15:42 ` Drew Adams @ 2010-03-02 16:02 ` Chong Yidong 2010-03-02 18:35 ` Drew Adams 0 siblings, 1 reply; 55+ messages in thread From: Chong Yidong @ 2010-03-02 16:02 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > How's feedback from Windows users working out for ya (and I don't mean > just build reports)? Gettin' any? The latest pretest has a couple of serious bugs on Windows, so IMO there is little point making the binary for it. ^ permalink raw reply [flat|nested] 55+ messages in thread
* RE: Emacs 23.1.93 pretest 2010-03-02 16:02 ` Chong Yidong @ 2010-03-02 18:35 ` Drew Adams 2010-03-02 19:53 ` Chong Yidong 0 siblings, 1 reply; 55+ messages in thread From: Drew Adams @ 2010-03-02 18:35 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: emacs-devel > The latest pretest has a couple of serious bugs on Windows, > so IMO there is little point making the binary for it. Fair enough. Is there a point in publishing a new release without testing on Windows, in particular, testing the fixes for those serious bugs? Or did you plan to publish another pretest with the bugs fixed? That would be good (normal). That wasn't clear from your mails. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Emacs 23.1.93 pretest 2010-03-02 18:35 ` Drew Adams @ 2010-03-02 19:53 ` Chong Yidong 0 siblings, 0 replies; 55+ messages in thread From: Chong Yidong @ 2010-03-02 19:53 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > Fair enough. Is there a point in publishing a new release without testing on > Windows, in particular, testing the fixes for those serious bugs? > > Or did you plan to publish another pretest with the bugs fixed? That would be > good (normal). That wasn't clear from your mails. There should be at least two more pretests before the 23.2 release. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-02-27 3:40 Emacs 23.1.93 pretest Chong Yidong 2010-02-27 9:05 ` Eli Zaretskii 2010-03-02 15:42 ` Drew Adams @ 2010-03-04 14:36 ` Sergei Organov 2010-03-04 15:57 ` Chong Yidong 2 siblings, 1 reply; 55+ messages in thread From: Sergei Organov @ 2010-03-04 14:36 UTC (permalink / raw) To: 5679; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 504 bytes --] Chong Yidong <cyd@stupidchicken.com> writes: > Emacs pretest 23.1.93 is now available for download via FTP, It incorrectly renders terminus oblique fonts from Debian distribution (xfonts-terminus-oblique Debian package): -xos4-terminus-medium-o-* -xos4-terminus-bold-o-* Small example screenshots from emacs 22.2.1 (correct rendering) and emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly "Global Mark Ring" looks when rendered by emacs23. NOTE: emacs 23.1.1 also renders wrong. [-- Attachment #2: emacs22 correct rendering --] [-- Type: image/png, Size: 7950 bytes --] [-- Attachment #3: emacs23 wrong rendering --] [-- Type: image/png, Size: 9031 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 14:36 ` bug#5679: " Sergei Organov @ 2010-03-04 15:57 ` Chong Yidong 2010-03-04 17:43 ` osv 0 siblings, 1 reply; 55+ messages in thread From: Chong Yidong @ 2010-03-04 15:57 UTC (permalink / raw) To: Sergei Organov; +Cc: 5679 [-- Attachment #1: Type: text/plain, Size: 630 bytes --] Sergei Organov <osv@javad.com> writes: > It incorrectly renders terminus oblique fonts from Debian distribution > (xfonts-terminus-oblique Debian package): > > -xos4-terminus-medium-o-* > -xos4-terminus-bold-o-* > > Small example screenshots from emacs 22.2.1 (correct rendering) and > emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly > "Global Mark Ring" looks when rendered by emacs23. > > NOTE: emacs 23.1.1 also renders wrong. I can't reproduce this---see attached screenshot, taken from 23.1.93. Please provide an exact recipe, including the exact .Xresources specification you use to choose the font. [-- Attachment #2: foo.png --] [-- Type: image/png, Size: 15306 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 15:57 ` Chong Yidong @ 2010-03-04 17:43 ` osv 2010-03-04 18:06 ` Chong Yidong 0 siblings, 1 reply; 55+ messages in thread From: osv @ 2010-03-04 17:43 UTC (permalink / raw) To: Chong Yidong; +Cc: 5679 [-- Attachment #1: Type: text/plain, Size: 5143 bytes --] Chong Yidong <cyd@stupidchicken.com> writes: > Sergei Organov <osv@javad.com> writes: > >> It incorrectly renders terminus oblique fonts from Debian distribution >> (xfonts-terminus-oblique Debian package): >> >> -xos4-terminus-medium-o-* >> -xos4-terminus-bold-o-* >> >> Small example screenshots from emacs 22.2.1 (correct rendering) and >> emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly >> "Global Mark Ring" looks when rendered by emacs23. >> >> NOTE: emacs 23.1.1 also renders wrong. > > I can't reproduce this---see attached screenshot, taken from 23.1.93. > Please provide an exact recipe, including the exact .Xresources > specification you use to choose the font. I don't use .Xresources. What I did was faces customization through customize. The simplest reproduction I came-up with is: $ emacs -q --no-site-file - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash screen - M-x customize-face <ENTER> <ENTER> - Change "Font Family:" to "terminus" - Select "State|Set for Current Session" - C-x b <ENTER> to return to splash screen, and /ABSOLUTELY NO WARRANTY/ looks like in the attached file. Here is result of report-emacs-bug after those steps: In GNU Emacs 23.1.93.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6) of 2010-03-04 on osv Windowing system distributor `The X.Org Foundation', version 11.0.10705000 configured using `configure '--prefix=/home/osv/emacs'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <down> <down> <down> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> M-x c u s t o m i z e - f a c e <return> <return> <help-echo> <down-mouse-1> <help-echo> <mouse-movement> <drag-mouse-1> C-w t e r m i n u s <help-echo> <help-echo> <down-mouse-1> C-x b <return> M-x r e p o r t <tab> <return> Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Creating customization items... Creating face editor...done Creating customization items ...done Resetting customization items...done Creating customization setup...done Load-path shadows: /home/osv/emacs/share/emacs/site-lisp/flim/md4 hides /home/osv/emacs/share/emacs/23.1.93/lisp/md4 /home/osv/emacs/share/emacs/site-lisp/flim/sha1 hides /home/osv/emacs/share/emacs/23.1.93/lisp/sha1 /home/osv/emacs/share/emacs/site-lisp/flim/hex-util hides /home/osv/emacs/share/emacs/23.1.93/lisp/hex-util /home/osv/emacs/share/emacs/site-lisp/flim/sasl-digest hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-digest /home/osv/emacs/share/emacs/site-lisp/flim/sasl hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl /home/osv/emacs/share/emacs/site-lisp/flim/sasl-cram hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-cram /home/osv/emacs/share/emacs/site-lisp/flim/hmac-def hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/hmac-def /home/osv/emacs/share/emacs/site-lisp/flim/ntlm hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/ntlm /home/osv/emacs/share/emacs/site-lisp/flim/hmac-md5 hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/hmac-md5 /home/osv/emacs/share/emacs/site-lisp/flim/sasl-ntlm hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-ntlm Features: (shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils mailheader canlock sha1 sha1-el hex-util hashcash mail-utils emacsbug crm thingatpt cus-edit easymenu cus-start cus-load wid-edit tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process font-render-setting gtk x-toolkit x multi-tty emacs) [-- Attachment #2: render.png --] [-- Type: image/png, Size: 1388 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 17:43 ` osv @ 2010-03-04 18:06 ` Chong Yidong 2010-03-04 19:22 ` osv 2010-03-10 6:23 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 55+ messages in thread From: Chong Yidong @ 2010-03-04 18:06 UTC (permalink / raw) To: osv; +Cc: 5679 <osv@javad.com> writes: > $ emacs -q --no-site-file > - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash > screen > - M-x customize-face <ENTER> <ENTER> > - Change "Font Family:" to "terminus" > - Select "State|Set for Current Session" > - C-x b <ENTER> to return to splash screen, and > > /ABSOLUTELY NO WARRANTY/ looks like in the attached file. Fraid I still can't reproduce this. One possibility I can think of is that the particular version of terminus you are using is buggy, and reports the right overhang incorrectly. Strange... ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 18:06 ` Chong Yidong @ 2010-03-04 19:22 ` osv 2010-03-09 0:05 ` YAMAMOTO Mitsuharu 2010-03-10 11:19 ` YAMAMOTO Mitsuharu 2010-03-10 6:23 ` YAMAMOTO Mitsuharu 1 sibling, 2 replies; 55+ messages in thread From: osv @ 2010-03-04 19:22 UTC (permalink / raw) To: Chong Yidong; +Cc: 5679 Chong Yidong <cyd@stupidchicken.com> writes: > <osv@javad.com> writes: > >> $ emacs -q --no-site-file >> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash >> screen >> - M-x customize-face <ENTER> <ENTER> >> - Change "Font Family:" to "terminus" >> - Select "State|Set for Current Session" >> - C-x b <ENTER> to return to splash screen, and >> >> /ABSOLUTELY NO WARRANTY/ looks like in the attached file. > > Fraid I still can't reproduce this. One possibility I can think of is > that the particular version of terminus you are using is buggy, and > reports the right overhang incorrectly. Strange... Yeah, it's really strange. I see it on 2 different computers running Debian stable and Debian testing. On both emacs23 gives this effect. And the fact that emacs22 renders fine means that it's probably not font issue, but maybe a problem of rendering library? What distribution do you use? In addition I've just checked that GNOME itself renders this font fine both in its font selection dialog and in gnome-terminal, so the only place where I can see the breakage is emacs run in X. Maybe to compile emacs with some other options to isolate the cause of the problem? BTW, emacs 23.1.1 only breaks rendering after I move cursor over the text. If I, for examle, select the text (active region so it's highlighted), the rendering becomes OK. Emacs 23.1.93 is more consistent and always renders bad. -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 19:22 ` osv @ 2010-03-09 0:05 ` YAMAMOTO Mitsuharu 2010-03-09 9:57 ` osv 2010-03-09 11:30 ` osv 2010-03-10 11:19 ` YAMAMOTO Mitsuharu 1 sibling, 2 replies; 55+ messages in thread From: YAMAMOTO Mitsuharu @ 2010-03-09 0:05 UTC (permalink / raw) To: osv; +Cc: Chong Yidong, 5679 >>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said: > Yeah, it's really strange. I see it on 2 different computers running > Debian stable and Debian testing. On both emacs23 gives this effect. > And the fact that emacs22 renders fine means that it's probably not > font issue, but maybe a problem of rendering library? What > distribution do you use? I couldn't reproduce it on Ubuntu 9.10. > In addition I've just checked that GNOME itself renders this font > fine both in its font selection dialog and in gnome-terminal, so the > only place where I can see the breakage is emacs run in X. Maybe to > compile emacs with some other options to isolate the cause of the > problem? It would be worth testing whether the problem is specific to a particular font backend or not. What happens if you replicate the steps on a frame created with (make-frame '((font-backend . (x)))) ? Also, could you try the following patch to see if it changes the situation? It is not meant to be a fix, but just for an experiment. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp === modified file 'src/xftfont.c' *** src/xftfont.c 2010-01-13 08:35:10 +0000 --- src/xftfont.c 2010-03-09 00:03:12 +0000 *************** *** 795,801 **** xftfont_driver.text_extents = xftfont_text_extents; xftfont_driver.draw = xftfont_draw; xftfont_driver.end_for_frame = xftfont_end_for_frame; ! xftfont_driver.cached_font_ok = xftfont_cached_font_ok; register_font_driver (&xftfont_driver, NULL); } --- 795,801 ---- xftfont_driver.text_extents = xftfont_text_extents; xftfont_driver.draw = xftfont_draw; xftfont_driver.end_for_frame = xftfont_end_for_frame; ! xftfont_driver.cached_font_ok = 0 /*xftfont_cached_font_ok*/; register_font_driver (&xftfont_driver, NULL); } ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-09 0:05 ` YAMAMOTO Mitsuharu @ 2010-03-09 9:57 ` osv 2010-03-09 11:30 ` osv 1 sibling, 0 replies; 55+ messages in thread From: osv @ 2010-03-09 9:57 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Chong Yidong, 5679 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes: >>>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said: > >> Yeah, it's really strange. I see it on 2 different computers running >> Debian stable and Debian testing. On both emacs23 gives this effect. >> And the fact that emacs22 renders fine means that it's probably not >> font issue, but maybe a problem of rendering library? What >> distribution do you use? > > I couldn't reproduce it on Ubuntu 9.10. > >> In addition I've just checked that GNOME itself renders this font >> fine both in its font selection dialog and in gnome-terminal, so the >> only place where I can see the breakage is emacs run in X. Maybe to >> compile emacs with some other options to isolate the cause of the >> problem? > > It would be worth testing whether the problem is specific to a > particular font backend or not. What happens if you replicate the > steps on a frame created with (make-frame '((font-backend . (x)))) ? It looks nice in the new frame, while still broken in the original frame. > > Also, could you try the following patch to see if it changes the > situation? It is not meant to be a fix, but just for an experiment. I'll check it a little bit later. -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-09 0:05 ` YAMAMOTO Mitsuharu 2010-03-09 9:57 ` osv @ 2010-03-09 11:30 ` osv 1 sibling, 0 replies; 55+ messages in thread From: osv @ 2010-03-09 11:30 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Chong Yidong, 5679 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes: >>>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said: > >> Yeah, it's really strange. I see it on 2 different computers running >> Debian stable and Debian testing. On both emacs23 gives this effect. >> And the fact that emacs22 renders fine means that it's probably not >> font issue, but maybe a problem of rendering library? What >> distribution do you use? > > I couldn't reproduce it on Ubuntu 9.10. > >> In addition I've just checked that GNOME itself renders this font >> fine both in its font selection dialog and in gnome-terminal, so the >> only place where I can see the breakage is emacs run in X. Maybe to >> compile emacs with some other options to isolate the cause of the >> problem? > > It would be worth testing whether the problem is specific to a > particular font backend or not. What happens if you replicate the > steps on a frame created with (make-frame '((font-backend . (x)))) ? > > Also, could you try the following patch to see if it changes the > situation? It is not meant to be a fix, but just for an experiment. I've tried the patch. It does not fix the problem. -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 19:22 ` osv 2010-03-09 0:05 ` YAMAMOTO Mitsuharu @ 2010-03-10 11:19 ` YAMAMOTO Mitsuharu 2010-03-10 11:29 ` osv 1 sibling, 1 reply; 55+ messages in thread From: YAMAMOTO Mitsuharu @ 2010-03-10 11:19 UTC (permalink / raw) To: osv; +Cc: Chong Yidong, 5679 >>>>> On Wed, 10 Mar 2010 13:05:07 +0300, <osv@javad.com> said: >> I tried installing the PCF fonts extracted from >> xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X >> 10.6. The result was: >> >> 1. I could reproduce the above problem on Emacs 23.1.92. >> 2. But I could also reproduce it on Emacs 23.1, unlike OP. > No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I > wrote in the original report: > " Small example screenshots from emacs 22.2.1 (correct rendering) > and emacs 23.1.93 (wrong rendering) are attached. Please notice how > ugly "Global Mark Ring" looks when rendered by emacs23. > NOTE: emacs 23.1.1 also renders wrong." I meant this one: >>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said: > BTW, emacs 23.1.1 only breaks rendering after I move cursor over the > text. If I, for examle, select the text (active region so it's > highlighted), the rendering becomes OK. Emacs 23.1.93 is more > consistent and always renders bad. I could not find the difference between the release version and the pretest one. Anyway, is `xterm -fa terminus:style=oblique' also broken? If so, we can conclude this is not a bug at the Emacs side. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-10 11:19 ` YAMAMOTO Mitsuharu @ 2010-03-10 11:29 ` osv 2010-03-10 11:54 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 55+ messages in thread From: osv @ 2010-03-10 11:29 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Chong Yidong, 5679 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes: >>>>>> On Wed, 10 Mar 2010 13:05:07 +0300, <osv@javad.com> said: > >>> I tried installing the PCF fonts extracted from >>> xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X >>> 10.6. The result was: >>> >>> 1. I could reproduce the above problem on Emacs 23.1.92. >>> 2. But I could also reproduce it on Emacs 23.1, unlike OP. > >> No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I >> wrote in the original report: > >> " Small example screenshots from emacs 22.2.1 (correct rendering) >> and emacs 23.1.93 (wrong rendering) are attached. Please notice how >> ugly "Global Mark Ring" looks when rendered by emacs23. > >> NOTE: emacs 23.1.1 also renders wrong." > > I meant this one: > >>>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said: > >> BTW, emacs 23.1.1 only breaks rendering after I move cursor over the >> text. If I, for examle, select the text (active region so it's >> highlighted), the rendering becomes OK. Emacs 23.1.93 is more >> consistent and always renders bad. > > I could not find the difference between the release version and the > pretest one. Well, I do see this difference indeed, but both render wrong anyway, so the difference is not essential, I think. > Anyway, is `xterm -fa terminus:style=oblique' also broken? If so, we > can conclude this is not a bug at the Emacs side. Yeah, this is broken as well. So please excuse my ignorance, but where exactly the problem is? I.e., why emacs 22 renders it fine? What is a work-around for emacs 23? -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-10 11:29 ` osv @ 2010-03-10 11:54 ` YAMAMOTO Mitsuharu 2010-03-10 12:12 ` osv 0 siblings, 1 reply; 55+ messages in thread From: YAMAMOTO Mitsuharu @ 2010-03-10 11:54 UTC (permalink / raw) To: osv; +Cc: Chong Yidong, 5679 >>>>> On Wed, 10 Mar 2010 14:29:59 +0300, <osv@javad.com> said: >> Anyway, is `xterm -fa terminus:style=oblique' also broken? If so, >> we can conclude this is not a bug at the Emacs side. > Yeah, this is broken as well. So please excuse my ignorance, but > where exactly the problem is? According to the experiments so far, it seems to be caused by Xft in addition to some conditions that are not yet sure (maybe library versions or settings?). > I.e., why emacs 22 renders it fine? What is a work-around for emacs > 23? Emacs 22 uses the traditional text drawing aka X core fonts, and many GNOME and GTK+ applications use cairo rather than Xft. A workaround would be to use the traditional text drawing as in Emacs 22 by preferring the X core font driver to the Xft one (see `fontBackend' in the "Table of X Resources for Emacs" node in the Emacs info). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-10 11:54 ` YAMAMOTO Mitsuharu @ 2010-03-10 12:12 ` osv 2010-03-11 0:38 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 55+ messages in thread From: osv @ 2010-03-10 12:12 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Chong Yidong, 5679 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes: >>>>>> On Wed, 10 Mar 2010 14:29:59 +0300, <osv@javad.com> said: > >>> Anyway, is `xterm -fa terminus:style=oblique' also broken? If so, >>> we can conclude this is not a bug at the Emacs side. > >> Yeah, this is broken as well. So please excuse my ignorance, but >> where exactly the problem is? > > According to the experiments so far, it seems to be caused by Xft in > addition to some conditions that are not yet sure (maybe library > versions or settings?). > >> I.e., why emacs 22 renders it fine? What is a work-around for emacs >> 23? > > Emacs 22 uses the traditional text drawing aka X core fonts, and many > GNOME and GTK+ applications use cairo rather than Xft. A workaround > would be to use the traditional text drawing as in Emacs 22 by > preferring the X core font driver to the Xft one (see `fontBackend' in > the "Table of X Resources for Emacs" node in the Emacs info). OK, adding Emacs.fontBackend: x,xft,cairo to my .Xdefaults fixed the problem, -- thanks a lot! -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-10 12:12 ` osv @ 2010-03-11 0:38 ` YAMAMOTO Mitsuharu 0 siblings, 0 replies; 55+ messages in thread From: YAMAMOTO Mitsuharu @ 2010-03-11 0:38 UTC (permalink / raw) To: osv; +Cc: Chong Yidong, 5679 [-- Attachment #1: Type: text/plain, Size: 845 bytes --] >>>>> On Wed, 10 Mar 2010 15:12:37 +0300, <osv@javad.com> said: >> Emacs 22 uses the traditional text drawing aka X core fonts, and >> many GNOME and GTK+ applications use cairo rather than Xft. A >> workaround would be to use the traditional text drawing as in Emacs >> 22 by preferring the X core font driver to the Xft one (see >> `fontBackend' in the "Table of X Resources for Emacs" node in the >> Emacs info). > OK, adding > Emacs.fontBackend: x,xft,cairo > to my .Xdefaults fixed the problem, -- thanks a lot! Currently Emacs doesn't provide the `cairo' font backend driver. Maybe it's not harmful if specified, but you can remove it. BTW, `xfd -fa terminus:style=oblique' would be more appropriate than `xterm ...' for showing that it is not a bug at the Emacs side. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp [-- Attachment #2: terminus-oblique.png --] [-- Type: image/png, Size: 7526 bytes --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-04 18:06 ` Chong Yidong 2010-03-04 19:22 ` osv @ 2010-03-10 6:23 ` YAMAMOTO Mitsuharu 2010-03-10 10:05 ` osv 1 sibling, 1 reply; 55+ messages in thread From: YAMAMOTO Mitsuharu @ 2010-03-10 6:23 UTC (permalink / raw) To: Chong Yidong; +Cc: 5679, osv >>>>> On Thu, 04 Mar 2010 13:06:35 -0500, Chong Yidong <cyd@stupidchicken.com> said: > <osv@javad.com> writes: >> $ emacs -q --no-site-file >> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash >> screen >> - M-x customize-face <ENTER> <ENTER> >> - Change "Font Family:" to "terminus" >> - Select "State|Set for Current Session" >> - C-x b <ENTER> to return to splash screen, and >> >> /ABSOLUTELY NO WARRANTY/ looks like in the attached file. > Fraid I still can't reproduce this. One possibility I can think of is > that the particular version of terminus you are using is buggy, and > reports the right overhang incorrectly. Strange... I tried installing the PCF fonts extracted from xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X 10.6. The result was: 1. I could reproduce the above problem on Emacs 23.1.92. 2. But I could also reproduce it on Emacs 23.1, unlike OP. 3. `xterm -fa terminus:style=oblique' showed the same problem. 4. I also tried my preliminary proof-of-concept cairo port (*) adjusted to Emacs 23.1.91, and it didn't show the problem. This explains why many GNOME and GTK+ apps don't show the problem with the same fonts. So, at least for my case, a possible explanation is that it is a problem in Xft drawing for some versions or settings. What's not explained is the inconsistency between the result 2 above and OP's experience with Emacs 23.1. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp (*) http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html ^ permalink raw reply [flat|nested] 55+ messages in thread
* bug#5679: Emacs 23.1.93 pretest 2010-03-10 6:23 ` YAMAMOTO Mitsuharu @ 2010-03-10 10:05 ` osv 0 siblings, 0 replies; 55+ messages in thread From: osv @ 2010-03-10 10:05 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: Chong Yidong, 5679 YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes: >>>>>> On Thu, 04 Mar 2010 13:06:35 -0500, Chong Yidong <cyd@stupidchicken.com> said: > >> <osv@javad.com> writes: >>> $ emacs -q --no-site-file >>> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash >>> screen >>> - M-x customize-face <ENTER> <ENTER> >>> - Change "Font Family:" to "terminus" >>> - Select "State|Set for Current Session" >>> - C-x b <ENTER> to return to splash screen, and >>> >>> /ABSOLUTELY NO WARRANTY/ looks like in the attached file. > >> Fraid I still can't reproduce this. One possibility I can think of is >> that the particular version of terminus you are using is buggy, and >> reports the right overhang incorrectly. Strange... > > I tried installing the PCF fonts extracted from > xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X 10.6. > The result was: > > 1. I could reproduce the above problem on Emacs 23.1.92. > 2. But I could also reproduce it on Emacs 23.1, unlike OP. No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I wrote in the original report: " Small example screenshots from emacs 22.2.1 (correct rendering) and emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly "Global Mark Ring" looks when rendered by emacs23. NOTE: emacs 23.1.1 also renders wrong." > 3. `xterm -fa terminus:style=oblique' showed the same problem. > 4. I also tried my preliminary proof-of-concept cairo port (*) > adjusted to Emacs 23.1.91, and it didn't show the problem. This > explains why many GNOME and GTK+ apps don't show the problem with > the same fonts. > > So, at least for my case, a possible explanation is that it is a > problem in Xft drawing for some versions or settings. What's not > explained is the inconsistency between the result 2 above and OP's > experience with Emacs 23.1. Emacs 23.1 behaves slightly different for me, but it still renders wrong, so there is no inconsistency here. -- Sergei. ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2010-03-11 0:38 UTC | newest] Thread overview: 55+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-02-27 3:40 Emacs 23.1.93 pretest Chong Yidong 2010-02-27 9:05 ` Eli Zaretskii 2010-02-27 10:21 ` Eli Zaretskii 2010-02-27 11:28 ` Juanma Barranquero 2010-02-27 12:11 ` Juanma Barranquero 2010-02-27 13:15 ` Eli Zaretskii 2010-02-27 14:14 ` Eli Zaretskii 2010-02-27 14:31 ` Andreas Schwab 2010-02-27 14:54 ` Eli Zaretskii 2010-02-27 14:59 ` Lennart Borgman 2010-02-27 15:29 ` Eli Zaretskii 2010-02-27 15:22 ` Chong Yidong 2010-02-27 18:58 ` Eli Zaretskii 2010-03-04 11:32 ` Kenichi Handa 2010-03-04 12:35 ` Jason Rumney 2010-02-27 15:39 ` Juanma Barranquero 2010-02-27 19:41 ` Stefan Monnier 2010-02-27 11:57 ` Eli Zaretskii 2010-02-27 19:03 ` Eli Zaretskii 2010-02-27 21:37 ` Chong Yidong 2010-02-27 22:22 ` Eli Zaretskii 2010-02-28 1:25 ` Chong Yidong 2010-02-28 17:21 ` Eli Zaretskii 2010-02-28 1:45 ` Chong Yidong 2010-02-28 10:46 ` Andreas Schwab 2010-02-28 14:25 ` Chong Yidong 2010-02-28 15:38 ` Andreas Schwab 2010-02-28 17:32 ` Eli Zaretskii 2010-02-28 19:31 ` Eli Zaretskii 2010-03-02 18:15 ` Eli Zaretskii 2010-03-02 19:53 ` Chong Yidong 2010-03-02 20:53 ` Eli Zaretskii 2010-03-04 11:24 ` Kenichi Handa 2010-02-28 17:34 ` Eli Zaretskii 2010-02-28 21:34 ` Chong Yidong 2010-02-28 17:15 ` Eli Zaretskii 2010-03-02 15:42 ` Drew Adams 2010-03-02 16:02 ` Chong Yidong 2010-03-02 18:35 ` Drew Adams 2010-03-02 19:53 ` Chong Yidong 2010-03-04 14:36 ` bug#5679: " Sergei Organov 2010-03-04 15:57 ` Chong Yidong 2010-03-04 17:43 ` osv 2010-03-04 18:06 ` Chong Yidong 2010-03-04 19:22 ` osv 2010-03-09 0:05 ` YAMAMOTO Mitsuharu 2010-03-09 9:57 ` osv 2010-03-09 11:30 ` osv 2010-03-10 11:19 ` YAMAMOTO Mitsuharu 2010-03-10 11:29 ` osv 2010-03-10 11:54 ` YAMAMOTO Mitsuharu 2010-03-10 12:12 ` osv 2010-03-11 0:38 ` YAMAMOTO Mitsuharu 2010-03-10 6:23 ` YAMAMOTO Mitsuharu 2010-03-10 10:05 ` osv
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.