* 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 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: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 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 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
` (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 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 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 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 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-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 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-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-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 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: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 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-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-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 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
* 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-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
* 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 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
* 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
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.