Bug with freewnn Japanese input method & XEmacs 21.5.33
Ailin Nemui writes:
Hi, I'm turning to XEmacs list for help,
a SUSE user has reported this problem and I can perfectly reproduce it,
but I'm not 100% sure where the error is. the wnn (input method library)
returns an error, but I think Emacs should handle that better than
crashing.
This code has worked fine for forever. That, combined with the
analysis below, leads me to believe you have a broken compiler. GCC
4.8.1 by any chance?
Here's what gdb reports about the crash:
Fatal error: assertion failed, file alloc.c, line 2870, length >=
0 && fullsize > 0
#9 0x0000000000464b12 in make_string (
contents=contents＠entry=0x7fff63302250 "mes_id = 203: Message not found.\n
\"usr/mitsutoshi/kihon.h\" mes_id = 203: Message not found.\nmes_id = 203:
Message not found.\n", length=-1) at alloc.c:3213
val = <optimized out>
#10 0x0000000000552c60 in yes_or_no (
s=s＠entry=0x7fff633024e0 "mes_id = 203: Message not found.\n
\"usr/mitsutoshi/kihon.h\" mes_id = 203: Message not found.\nmes_id = 203:
Message not found.\n")
at mule-wnnfns.c:2125
yes = <optimized out>
str = 140734857487584
gcpro1 = {next = 0x100, var = 0x7fa8a0accd7d, nvars = 1664099224}
mbuf = "mes_id = 203: Message not found.\n
\"usr/mitsutoshi/kihon.h\" mes_id = 203: Message not found.\nmes_id = 203:
Message not
found.\n\000\000\000\000#0c\004\000\000\000\360\"0c\377\177\000\000\000\000\377\377",
'\000' <repeats 12 times>, "\377\377\377\377\000\000\000\000
\312%\236\250\177", '\000' <repeats 18 times>,
"＠#0c\377\177\000\000"...
charset = <optimized out>
len = <optimized out>
Here's the code that triggers the assertion:
for (len = 0; (mbuf[len]) && (len < 512); len++);
for (; (mbuf[len] != '(') && (len > 0); len--);
{
Lisp_Object yes, str;
struct gcpro gcpro1;
str = make_string (mbuf, len);
GCPRO1 (str);
yes = call1 (Qyes_or_no_p, str);
UNGCPRO;
if (NILP (yes)) return 0;
else return (1);
}
In the call to make_string, len = -1. I don't see how a correct
compilation can get there. Note that both loops have no body. (The
braces are simply there to allow 'yes', 'str', and 'gcpro1' to be
local variables of very limited scope.) So somehow len starts at 0,
weakly increases to a number at most 511, weakly decreases to at least
0. (And no, make_string doesn't tweak len before passing to
make_unit_string; I checked.)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta