7:38 a.m.
Hi!
make bindist currently has a hard landing:
gmake[3]: Entering directory `/usr/local/users/support/nk/cvs/xemacs-packages/co
mm/tm/texi'
xemacs -batch -q -no-site-file tm-ja.texi \
-eval '(unless (featurep (quote mule)) (kill-emacs 0))' \
-l texinfmt -f texinfo-format-buffer \
-eval '(setq file-coding-system (quote iso-2022-7))' \
-eval '(save-buffer 0)'
Formatting Info file...
Formatting Info file: tm-ja.info
Converting tm-ja.texi to Info format...
Removing trailing whitespace from Info buffer...
Formatting: tm 7.100 Manual~~~~~~ ...
Formatting: tm ~~~~ ...
Formatting: ~~ ...
Formatting: 7bit ... Fatal error: assertion failed, file insdel.c, line 1122, VA
LID_BYTIND_P (buf, x)
gmake[3]: *** [tm-ja.info] Abort trap (core dumped)
gmake[3]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m/tm/texi'
gmake[2]: *** [texi] Error 2
gmake[2]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m/tm'
gmake[1]: *** [tm/bindist.target] Error 2
gmake[1]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/com
m'
gmake: *** [comm/bindist.target] Error 2
xemacs expands to
"XEmacs 21.2 (beta44) \"Thalia\" [Lucid] (i386-unknown-freebsd3.3,
Mule) of Sun Feb 18 2001 on lamia.LF.net"
The c-trace is
#0 0x1856b3d0 in kill () from /usr/lib/libc.so.3
#1 0x1859f728 in abort () from /usr/lib/libc.so.3
#2 0x80c977a in assert_failed (file=0x82eaa51 "insdel.c", line=1122,
expr=0x82ea44f "VALID_BYTIND_P (buf, x)") at emacs.c:3214
#3 0x8190d52 in bytind_to_bufpos (buf=0x8464200, x=203) at insdel.c:1122
#4 0x81dbeaa in re_match_2 (bufp=0x83f55b4,
string1=0x857116f "\222¤·\222¤«\222¤·\222¡¢7bit
\222¤Ç\222¤¢\222¤ì\222¤Ð\222¤É\222¤ó\222¤Ê data
\222¤Ç\222¤â\222ÎÉ\222¤¤\222¤È\222¤Ï\222¤¤\222¤¨\222¤Ê\222¤¤\222¡£\222¤Ê\222¤¼\222¤Ê\222¤é\222¡¢\222£±\222¹Ô\222¤Î",
size1=101,
string2=0x85718ab
"\222Ĺ\222¤µ\222¤¬\222¤¢\222¤Þ\222¤ê\222¤Ë\222Ĺ\222¤¤\222¤È\222¡¢MTA
\222¤Ï\222¤½\222¤Î message
\222¤ò\222ž\222Á÷\222¤¹\222¤ë\222¤³\222¤È\222¤¬\222¤Ç\222¤\222¤Ê\222¤¤\222¤«\222¤é\222¤Ç\n\222¤¢\222¤ë\222¡£\222¤Á\222¤Ê\222¤ß\222¤Ë\222¡¢RFC
821 (*Note RFC 821::)
\222¤Ï\222£±\222¹Ô\222¤Ï\222²þ\222¹Ô\222ʸ\222»ú\222¤ò\222½ü\222¤¤\222¤Æ 998\nbyte
\222°Ê"..., size2=406,
pos=202, regs=0x83f6bf4, stop=507) at regex.c:4327
#5 0x81e1c8c in looking_at_1 (string={gu = {type = Lisp_Type_Record,
val = 102480089}, s = {bits = 0, val = 204960178}, u = {bits = 0,
val = 204960178}, ui = 409920356, i = 409920356, v = 0x186ee364,
cv = 0x186ee364}, buf=0x8464200, posix=0) at search.c:320
#6 0x81e8462 in Flooking_at (regexp={gu = {type = Lisp_Type_Record,
val = 102480089}, s = {bits = 0, val = 204960178}, u = {bits = 0,
val = 204960178}, ui = 409920356, i = 409920356, v = 0x186ee364,
cv = 0x186ee364}, buffer={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at search.c:352
#7 0x80cfdea in Ffuncall (nargs=2, args=0xbfbfc450) at eval.c:3528
#8 0x809d79e in execute_optimized_program (
program=0x8530410
"\016B«\r\016BÆa¬\a`\016BB\026B\r\013^b\210\r\013]\023ÇÈw\210`È\036C\036EÉy\210`\025\013b\210`\rV«%`SfÊa«\036\016C«\022\016J«\bË`SÌ\"¬\aÍÎ!\210ªàÏu\210Æ\026CªØ`\023\016C¬\n\013\016EV«\004Ð
\210\016Eb\210*\013`V\205\006\003\n¬\004Ñ
\022\f\034Ò\r\013Æ#\210\214\rb\210Éy\210`\013}\210\n¬\032\rb\210m\204Ü\002l¬\013Ó Ô
W«\004Õ \210Îy\210ªë\016J«\aÖ\rd×#\210\nØs¬\bÓ Ô W«\004Õ
\210\rb\210\f\r\fÙk?\a"..., stack_depth=7, constants_data=0x18695208)
at bytecode.c:746
#9 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102497123}, s = {bits = 0,
val = 204994246}, u = {bits = 0, val = 204994246}, ui = 409988492,
i = 409988492, v = 0x186fed8c, cv = 0x186fed8c}, nargs=3,
args=0xbfbfc5b4) at bytecode.c:518
#10 0x80cfee5 in Ffuncall (nargs=4, args=0xbfbfc5b0) at eval.c:3563
#11 0x809d79e in execute_optimized_program (
program=0x8428710 "\r«\013\rÆ\035\211\030\f!*®)`\031\212Ç \210n¬\005ÈÉ!\210`Ê
\210`\e\032\tb\210\016\r«\bË\013\n\f#ª\006Ì\013\n\f#,\207\bchapter \016\t",
stack_depth=5, constants_data=0x1868f4d8) at bytecode.c:746
#12 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102494743}, s = {bits = 0,
val = 204989486}, u = {bits = 0, val = 204989486}, ui = 409978972,
i = 409978972, v = 0x186fc85c, cv = 0x186fc85c}, nargs=1,
args=0xbfbfc714) at bytecode.c:518
#13 0x80cfee5 in Ffuncall (nargs=2, args=0xbfbfc710) at eval.c:3563
#14 0x809d79e in execute_optimized_program (
program=0x8428f90 "Æ \210Ç
\eÈÉ!\210ÊË!«\004Ìy\210\212Éy\210ÊÍ!)«\rÉy\210`Ìy\210`|\210ª\031\nÎk¬\024\tÏV¬\017`ÐÑw\210`|\210Ò\nÓ\"c\210ÈÌ!\210Éy\210Ñ\177\210\r\030\rÔP\035\f\036\027\fÔP\034Õ\216ÖÑ!\210-\013b)\207",
stack_depth=3,
constants_data=0x84d9a90) at bytecode.c:746
#15 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34857374}, s = {bits = 0,
val = 69714748}, u = {bits = 0, val = 69714748}, ui = 139429496,
i = 139429496, v = 0x84f8678, cv = 0x84f8678}, nargs=0, args=0xbfbfc864)
at bytecode.c:518
#16 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfc860) at eval.c:3563
#17 0x809d79e in execute_optimized_program (
program=0x852a810 "Æed\"\210eb\210ÇÈÉÊ#\203Ü", stack_depth=5,
constants_data=0x852f810) at bytecode.c:746
#18 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901652}, s = {bits = 0,
val = 69803304}, u = {bits = 0, val = 69803304}, ui = 139606608,
i = 139606608, v = 0x8523a50, cv = 0x8523a50}, nargs=0, args=0xbfbfc9c4)
at bytecode.c:518
#19 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfc9c0) at eval.c:3563
#20 0x809d79e in execute_optimized_program (
program=0x8464410 "Æ", '\211' <repeats 14 times>,
"ÇÆ\211\bp\016?\0367\035\0368\034\036＠\036A\036B\036C\0369\036:\036;\036<\036=\036>\036D\036E\036F\e\036G\036H\032Æ\211\026I\026J\212eb\210ÈÉÆÊ#¬\005ËÌ!\210`\023Í
\024)Î\f!\210Ï \210Ð
\210ÑÒ\f\"\210ÓÔ\f!!\022\0168\020Õ\016K!\210Ö\r!\210Ñ×Ø\r!\"\210eb\210\212ÑÙ!\210ÚÛÆÊ#«\tÜÝÆ\211#\210ªò)ÚÞÆÊ#«E`\023\0167Í
P\031ßÞ!\210`\212ày\210`)|\210Ñá\t\"\210\212\214``â\t!A＠\\}\210eb\210Ú"...,
stack_depth=22, constants_data=0x853cc10)
at bytecode.c:746
#21 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901624}, s = {bits = 0,
val = 69803248}, u = {bits = 0, val = 69803248}, ui = 139606496,
i = 139606496, v = 0x85239e0, cv = 0x85239e0}, nargs=0, args=0xbfbfcb64)
at bytecode.c:518
#22 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfcb60) at eval.c:3563
#23 0x809d79e in execute_optimized_program (
program=0x84f7090 "Â\031Ã\t!\210~\210Ä \210Å \210\b¬\020Æ ÇV«\nÃÈ\211\021!\210É
\210Ã\tt«\004ʪ\002ËP!)\207lin\apO\b", stack_depth=3,
constants_data=0x84f7c90) at bytecode.c:746
#24 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 34901603}, s = {bits = 0,
val = 69803206}, u = {bits = 0, val = 69803206}, ui = 139606412,
i = 139606412, v = 0x852398c, cv = 0x852398c}, nargs=0, args=0xbfbfccb4)
at bytecode.c:518
#25 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfccb0) at eval.c:3563
#26 0x809d79e in execute_optimized_program (
program=0x847c690 "Á\b\211A\020＠! \207w`\030DØS\b\026ÀG\b\200êL\bR\005",
stack_depth=3, constants_data=0x18685bac) at bytecode.c:746
#27 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491705}, s = {bits = 0,
val = 204983410}, u = {bits = 0, val = 204983410}, ui = 409966820,
i = 409966820, v = 0x186f98e4, cv = 0x186f98e4}, nargs=1,
args=0xbfbfce04) at bytecode.c:518
#28 0x80cfee5 in Ffuncall (nargs=2, args=0xbfbfce00) at eval.c:3563
#29 0x809d79e in execute_optimized_program (
program=0x84fa110 "\n¬＠\016!?\205Ñ", stack_depth=7,
constants_data=0x18684218) at bytecode.c:746
#30 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491040}, s = {bits = 0,
val = 204982080}, u = {bits = 0, val = 204982080}, ui = 409964160,
i = 409964160, v = 0x186f8e80, cv = 0x186f8e80}, nargs=0,
args=0xbfbfcf64) at bytecode.c:518
#31 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfcf60) at eval.c:3563
#32 0x809d79e in execute_optimized_program (
program=0x8445c90 "\013A\035ÆÇ\032\031È\r!\025ÉÊ!«\004Ë
\210\f«\016\b¬\013ÌÍÎ\f!ÏQ! \210Ð \210*Ñ \210Ò \210rÓÔ!q\210Õ
\210Ö×!\210\016\036Øa«\005\016\037 \210)Ù Úa«\bÀ ¬\004Û \210Ü \210×\026 À
\004ÝÇ!)\207", stack_depth=4,
constants_data=0x18684b68) at bytecode.c:746
#33 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491236}, s = {bits = 0,
val = 204982472}, u = {bits = 0, val = 204982472}, ui = 409964944,
i = 409964944, v = 0x186f9190, cv = 0x186f9190}, nargs=0,
args=0xbfbfd0c4) at bytecode.c:518
#34 0x80cfee5 in Ffuncall (nargs=1, args=0xbfbfd0c0) at eval.c:3563
#35 0x809d79e in execute_optimized_program (
program=0x8435510 "\t«\005ÆÇ!\207È\021É
\211\034«\025\fG\rGW«\016Ê\r!Ê\f!k«\005Ë\f!\025)Ì\r!\025Í \210Î
\210\013®\aÏÐ!\002È\eÑ\016#\016$\"\022\013«\tÒÓÔ\n\"Õ\"\210\n¬\004Ö
\210×\n\016%\b\016&\013%\210Ø
\210)\016!¬\022\016\"«\016ÙÚÛ\016'!\016\"\"ÜÈ#\210\016!¬\023\b¬\006Ý\016(!\210Ý\016)!\210Ý\016*!\210Þ\216ß
\210)\016+\003à \207O8859-1\niso8859-15/XLC_LOCALE\tde_LI.ISO8859-15\niso"...,
stack_depth=7, constants_data=0x18685298) at bytecode.c:746
#36 0x809d3b3 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 102491453}, s = {bits = 0,
val = 204982906}, u = {bits = 0, val = 204982906}, ui = 409965812,
i = 409965812, v = 0x186f94f4, cv = 0x186f94f4}, nargs=0,
args=0xbfbfd19c) at bytecode.c:518
#37 0x80cf6cb in Feval (form={gu = {type = Lisp_Type_Record, val = 102271649},
s = {bits = 0, val = 204543298}, u = {bits = 0, val = 204543298},
ui = 409086596, i = 409086596, v = 0x18622a84, cv = 0x18622a84})
at eval.c:3388
#38 0x80d5a9a in condition_case_1 (handlers={gu = {type = Lisp_Type_Record,
val = 102248666}, s = {bits = 0, val = 204497332}, u = {bits = 0,
val = 204497332}, ui = 408994664, i = 408994664, v = 0x1860c368,
cv = 0x1860c368}, bfun=0x80ceb50 <Feval>, barg={gu = {
type = Lisp_Type_Record, val = 102271649}, s = {bits = 0,
val = 204543298}, u = {bits = 0, val = 204543298}, ui = 409086596,
i = 409086596, v = 0x18622a84, cv = 0x18622a84},
hfun=0x80ad5b4 <cmd_error>, harg={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at eval.c:1651
#39 0x80ad640 in top_level_1 (dummy={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at cmdloop.c:206
#40 0x80d599c in internal_catch (tag={gu = {type = Lisp_Type_Record,
val = 102200162}, s = {bits = 0, val = 204400324}, u = {bits = 0,
val = 204400324}, ui = 408800648, i = 408800648, v = 0x185dcd88,
cv = 0x185dcd88}, func=0x80ad610 <top_level_1>, arg={gu = {
type = Lisp_Type_Record, val = 102248762}, s = {bits = 0,
val = 204497524}, u = {bits = 0, val = 204497524}, ui = 408995048,
i = 408995048, v = 0x1860c4e8, cv = 0x1860c4e8}, threw=0x0)
at eval.c:1317
#41 0x80ac867 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record,
val = 102248762}, s = {bits = 0, val = 204497524}, u = {bits = 0,
val = 204497524}, ui = 408995048, i = 408995048, v = 0x1860c4e8,
cv = 0x1860c4e8}) at cmdloop.c:285
#42 0x80c78c1 in xemacs_21_2_b44_i386_unknown_freebsd3_3 (argc=15,
argv=0xbfbfd4f0, envp=0xbfbfd530, restart=0) at emacs.c:2253
#43 0x80c999e in main (argc=15, argv=0xbfbfd4f0, envp=0xbfbfd530)
at emacs.c:2620
norbert.
7:59 a.m.
-- Norbert Koch <nk(a)LF.net> spake thusly:
make bindist currently has a hard landing:
> gmake[3]: Entering directory
`/usr/local/users/support/nk/cvs/xemacs-packages/co mm/tm/texi'
xemacs -batch -q -no-site-file tm-ja.texi \
-eval '(unless (featurep (quote mule)) (kill-emacs 0))' \
-l texinfmt -f texinfo-format-buffer \
-eval '(setq file-coding-system (quote iso-2022-7))' \
-eval '(save-buffer 0)'
Formatting Info file...
Formatting Info file: tm-ja.info
Converting tm-ja.texi to Info format...
Removing trailing whitespace from Info buffer...
Formatting: tm 7.100 Manual~~~~~~ ... > Formatting: tm ~~~~ ... > Formatting: ~~
... > Formatting: 7bit ... Fatal error: assertion failed, file insdel.c,
line 1122, VALID_BYTIND_P (buf, x)
...
#2 0x80c977a in assert_failed (file=0x82eaa51 "insdel.c",
line=1122, > expr=0x82ea44f "VALID_BYTIND_P (buf, x)") at emacs.c:3214
#3 0x8190d52 in bytind_to_bufpos (buf=0x8464200, x=203) at
insdel.c:1122 #4 0x81dbeaa in re_match_2 (bufp=0x83f55b4, > string1=0x857116f
"\222¤·\222¤«\222¤·\222¡¢7bit
\222¤Ç\222¤¢\222¤ì\222¤Ð\222¤É\222¤ó\222¤Ê data
\222¤Ç\222¤â\222ÎÉ\222¤¤\222¤È\222¤Ï\222¤¤\222¤¨\222¤Ê\222¤¤\222¡
£\222¤Ê\222¤¼\222¤Ê\222¤é\222¡¢\222£±\222¹Ô\222¤Î", size1=101, >
string2=0x85718ab
"\222Ĺ\222¤µ\222¤¬\222¤¢\222¤Þ\222¤ê\222¤Ë\222Ĺ\222¤¤\222¤È\222
¡¢MTA \222¤Ï\222¤½\222¤Î message
\222¤ò\222ž\222Á÷\222¤¹\222¤ë\222¤³\222¤È\222¤¬\222¤Ç\222¤\222¤
Ê\222¤¤\222¤«\222¤é\222¤Ç\n\222¤¢\222¤ë\222¡£\222¤Á\222¤Ê\222¤ß\2
22¤Ë\222¡¢RFC 821 (*Note RFC 821::)
\222¤Ï\222£±\222¹Ô\222¤Ï\222²þ\222¹Ô\222ʸ\222»ú\222¤ò\222½ü\222¤
¤\222¤Æ 998\nbyte \222°Ê"..., size2=406, pos=202,
regs=0x83f6bf4, stop=507) at regex.c:4327
This one's the syntax stuff again. I'm pretty sure that all of these
'VALID_BYTIND_P' crashes (there are at least three that I know of) are
the same error, or at least related. Fortunately this particular one is
easily reproducible on my system, so I'm sure I'll be able to get this
figured out within the next day or two.
Thanks for the report, Norbert.
12:23 p.m.
>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> This one's the syntax stuff again. I'm pretty sure that all
Matt> of these 'VALID_BYTIND_P' crashes (there are at least three
Matt> that I know of) are the same error, or at least
Matt> related. Fortunately this particular one is easily
Matt> reproducible on my system, so I'm sure I'll be able to get
Matt> this figured out within the next day or two.
I got this one, same stack trace as Norbert, I think.
The offending code in my dump seems to be at 4319 of regex.c:
#ifdef emacs
{
int adjpos = NILP (regex_match_object) || BUFFERP (regex_match_object) ? 1 : 0;
SETUP_SYNTAX_CACHE_FOR_OBJECT (regex_match_object,
regex_emacs_buffer,
SYNTAX_CACHE_OBJECT_BYTE_TO_CHAR (regex_match_object,
regex_emacs_buffer,
pos + adjpos),
1);
}
#endif
The problem is apparently in the assumption that adjpos is 0 or 1.
The regex code works on bytes, not on Mule characters, assuming that
both the regexp and the target text are properly formatted Mule text.
(Cf comment at head of re_search_2. A little reflection will show
that this will work as long as you are careful about compiling the
regexp, treating Mule characters as concatenated bytes, with
exceptions like "match any character", which only matches leading
bytes and then must "jump over" any trailing bytes.) So adjpos is a
variable which depends on the current character's size.
I suspect the correct idiom is to use INC_CHARPTR on pos. You should
_not_ use VALIDATE_CHARPTR_FORWARD on (pos + adjpos), as that assumes
that you are not at the last character in the string. I don't see how
you can test that without more trouble than its worth. See buffer.h,
starting about l. 265 for lots of caveats about this kind of thing.
These changes may require fiddling with the new code (changing array
manipulations to pointer idioms, eg) to get them to make sense.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
7:34 a.m.
>>>> "sjt" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> This one's the syntax stuff
again. I'm pretty sure that all
Matt> of these 'VALID_BYTIND_P' crashes (there are at least three
Matt> that I know of) are the same error
sjt> I got this one, same stack trace as Norbert, I think.
sjt> The offending code in my dump seems to be at 4319 of regex.c:
sjt> These changes may require fiddling with the new code
sjt> (changing array manipulations to pointer idioms, eg) to get
sjt> them to make sense.
Some more on this. First, the same code occurs in re_search_2 at line
4042. It needs to be fixed there as well.
I wonder if re_match_2 is the right place for this adjustment.
Shouldn't it be done in re_match_2_internal? (re_search_2 needs to be
checked for this issue too.)
The proper idiom uses the re_char* variable d (eg, from re_search_2
line 4187):
d = ((const unsigned char *)
(startpos >= size1 ? string2 - size1 : string1) + startpos);
d_size = charcount_to_bytecount (d, 1);
range -= d_size;
startpos += d_size;
I'm not sure if you can use `d' in re_match_2(_internal)? because it
seems to be used in a different way from re_search_2. This idiom
doesn't seem to appear in re_match_2_internal at all. I suppose this
is because there is no issue of "skipping" characters since the re is
anchored at point.
This idiom recurs often. It probably ought to be encapsulated in a
set of macros. (That's not your job unless you volunteer for
it---Martin is good at that kind of thing and might be willing to
help. Definitely it can't be included in the release.)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:03 a.m.
-- "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> spake thusly:
>>>>> "sjt" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Matt" == Matt Tucker <tuck(a)whistlingfish.net>
writes:
Matt> This one's the syntax stuff again. I'm pretty sure that all
Matt> of these 'VALID_BYTIND_P' crashes (there are at least three
Matt> that I know of) are the same error
sjt> I got this one, same stack trace as Norbert, I think.
sjt> The offending code in my dump seems to be at 4319 of regex.c:
sjt> These changes may require fiddling with the new code
sjt> (changing array manipulations to pointer idioms, eg) to get
sjt> them to make sense.
Some more on this. First, the same code occurs in re_search_2 at line
4042. It needs to be fixed there as well.
I wonder if re_match_2 is the right place for this adjustment.
Shouldn't it be done in re_match_2_internal? (re_search_2 needs to be
checked for this issue too.)
The proper idiom uses the re_char* variable d (eg, from re_search_2
line 4187):
d = ((const unsigned char *)
(startpos >= size1 ? string2 - size1 : string1) + startpos);
d_size = charcount_to_bytecount (d, 1);
range -= d_size;
startpos += d_size;
I'm not sure if you can use `d' in re_match_2(_internal)? because it
seems to be used in a different way from re_search_2. This idiom
doesn't seem to appear in re_match_2_internal at all. I suppose this
is because there is no issue of "skipping" characters since the re is
anchored at point.
This idiom recurs often. It probably ought to be encapsulated in a
set of macros. (That's not your job unless you volunteer for
it---Martin is good at that kind of thing and might be willing to
help. Definitely it can't be included in the release.)
I'm pretty sure I've got it nailed down now. The adjpos was a false
lead. It had nothing to do with mule characters; it was used to
accomodate for the fact that buffers are indexed from 1 and strings are
indexed from 0.
The real problem was that the code in regex.c converts from byte
indices to bufpos's, but the macros I was using in syntax.h weren't
taking narrowed buffers into account (I had to rewrite them when
porting from the GNU code, and somehow lost that bit). This was showing
up most commonly in info buffers, where narrowing is frequently used.
I'm now properly offsetting by BI_BUF_BEGV. Interestingly, this
obviates the need for adjpos (apparently the GNU code had regex.c
adding the 1 for buffers and then then syntax.h macros were subtracting
it again; true weirdness).
I tested the fix against the bindist snippet and it worked fine. I'm
fairly certain I'm doing the right thing now, so I'm going to go ahead
and commit tonight (despite the fact that it's way past my bedtime),
but I'll look at it again in the morning just to be sure.
9:36 a.m.
-- Norbert Koch <nk(a)LF.net> spake thusly:
If I open a mail containing a German umlaut, I'll get a core
dump.
The Lisp-backtrace ends in
string-match("\\b[^＠ <>]+[!＠][^＠ <>]+\\b" "Isabelle
Tr\xf6ndle
<I.Troendle(a)delmia.de>") ^
|
hex representation
#3 0x80c92da in assert_failed (file=0x82ea4f1 "insdel.c", line=1122,
expr=0x82e9eef "VALID_BYTIND_P (buf, x)") at emacs.c:3214
-- Evgeny Roubinchtein <evgenyr(a)cs.washington.edu> spake thusly:
xemacs -vanilla
C-h i
Kaboom!
...
And here's gdb stack trace:
#3 0x80bf165 in assert_failed (file=0x828bb00
"/usr/local/xemacs/beta/src/insdel.c", line=1122, expr=0x828b2cf
"VALID_BYTIND_P (buf, x)")
at /usr/local/xemacs/beta/src/emacs.c:3214
-- Norbert Koch <nk(a)LF.net> spake thusly:
make bindist currently has a hard landing:
...
Formatting: 7bit ... Fatal error: assertion failed, file insdel.c,
line 1122, VALID_BYTIND_P (buf, x)
...
#2 0x80c977a in assert_failed (file=0x82eaa51 "insdel.c",
line=1122,
expr=0x82ea44f "VALID_BYTIND_P (buf, x)") at emacs.c:3214
I just committed the fix for these and related issues to CVS. Could you
please test the latest code to make sure it fixes these issues? Thanks.
10:12 a.m.
Matt Tucker <tuck(a)whistlingfish.net> writes:
Hi Matt!
I just committed the fix for these and related issues to CVS. Could
you
please test the latest code to make sure it fixes these issues? Thanks.
I'm able to read the mails and I'm able to build the package, thanks.
Although, in trying to create this reply I got a new core, probably
related. See my other post.
norbert.
11:28 a.m.
Matt Tucker <tuck(a)whistlingfish.net> writes:
I just committed the fix for these and related issues to CVS. Could
you
please test the latest code to make sure it fixes these issues? Thanks.
It fixed the crash I was seeing. Thank you! (that was fast!)
--
Evgeny
SGD: Spin and Granulate Disks
8474
days inactive
8476
days old
7 comments
4 participants
participants (4)
-
Evgeny Roubinchtein -
Matt Tucker -
Norbert Koch -
Stephen J. Turnbull