1:07 a.m.
On my Solaris 5.8 machines here at work, when running 'make TAGS' with
a 21.4.16 build, I'm getting a segv running etags.
Here's the backtrace:
#0 0x00021ba4 in regex_compile (
pattern=0xffbefada "[ \t]*DEF\\(VAR\\|INE\\)_[A-Z_]+[ \t]*([
\t]*\"\\([^\"]+\\)\"", size=50,
syntax=512, bufp=0x45ea8) at /u/sheltonv/software/src/xemacs-21.4.16/src/regex.c:2008
#1 0x0002fa10 in re_compile_pattern (
pattern=0xffbefada "[ \t]*DEF\\(VAR\\|INE\\)_[A-Z_]+[ \t]*([
\t]*\"\\([^\"]+\\)\"", length=50,
bufp=0x45ea8) at /u/sheltonv/software/src/xemacs-21.4.16/src/regex.c:6251
#2 0x0001e5b4 in add_regex (
regexp_pattern=0xffbefada "[ \t]*DEF\\(VAR\\|INE\\)_[A-Z_]+[ \t]*([
\t]*\"\\([^\"]+\\)\"",
ignore_case=0, lang=0x0) at
/u/sheltonv/software/src/xemacs-21.4.16/lib-src/etags.c:5175
#3 0x0001e458 in analyse_regex (
regex_arg=0xffbefada "[ \t]*DEF\\(VAR\\|INE\\)_[A-Z_]+[ \t]*([
\t]*\"\\([^\"]+\\)\"",
ignore_case=0) at /u/sheltonv/software/src/xemacs-21.4.16/lib-src/etags.c:5136
#4 0x000127e4 in main (argc=5, argv=0xffbef974)
at /u/sheltonv/software/src/xemacs-21.4.16/lib-src/etags.c:1133
Here's what I found:
(gdb) p bufp
$3 = (struct re_pattern_buffer *) 0x45ea8
(gdb) p *bufp
$4 = {buffer = 0x0, allocated = 0, used = 0, syntax = 512, fastmap = 0x0, translate = 0x0,
re_nsub = 0, re_ngroups = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0,
no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 1,
external_to_internal_register = 0x75736572, external_to_internal_register_size =
286368}
(The values for both external_to_internal_register and
external_to_internal_register_size looked potentially suspicious to me
- bufp was newly allocated in add_regex just before the call to
re_compile_pattern.)
In regex.c, at line 2004, there's the following check:
if (bufp->external_to_internal_register == 0)
{
bufp->external_to_internal_register_size = INIT_REG_TRANSLATE_SIZE;
RETALLOC (bufp->external_to_internal_register,
bufp->external_to_internal_register_size,
int);
}
So, I set external_to_internal_register to 0 and the crash went away.
Patch included here:
--- xemacs-21.4.16/lib-src/etags.c 2004-06-24 00:02:29.000000000 -0400
+++ xemacs-21.4.16/lib-src/etags.c-works 2004-12-16 15:44:56.109304000 -0500
＠＠ -5171,6 +5171,7 ＠＠
patbuf->fastmap = NULL;
patbuf->buffer = NULL;
patbuf->allocated = 0;
+ patbuf->external_to_internal_register = 0;
err = re_compile_pattern (regexp_pattern, strlen (regexp_pattern), patbuf);
if (err != NULL)
But, this can't be right, can it? patbuf is allocated in etags.c and
it looks like it's not fully initialized, but if this fix is right,
how could the code ever have worked?
Thanks for any help you can offer,
Vin
--
In a minute there is time
For decisions and revisions which a minute will reverse. T.S. Eliot
[URL: http://www.cs.amherst.edu/~ccm/prufrock.html]
2:14 a.m.
Vin,
I will look into this bug as soon as possible and contact you back.
Thanks for the report.
9:13 a.m.
So, I set external_to_internal_register to 0 and the crash went away.
Patch included here:
--- xemacs-21.4.16/lib-src/etags.c 2004-06-24 00:02:29.000000000 -0400
+++ xemacs-21.4.16/lib-src/etags.c-works 2004-12-16 15:44:56.109304000 -0500
＠＠ -5171,6 +5171,7 ＠＠
patbuf->fastmap = NULL;
patbuf->buffer = NULL;
patbuf->allocated = 0;
+ patbuf->external_to_internal_register = 0;
err = re_compile_pattern (regexp_pattern, strlen (regexp_pattern), patbuf);
if (err != NULL)
But, this can't be right, can it?
It can, yes. But etags has completely zeroed the pattern buffer before
using it for three and a half years, looking forward to changes like the
one that hit you. You are using a very old version.
You can dowload the latest version from
<ftp://fly.isti.cnr.it/pub/etags.c.gz>
or, if you want the man page, a statically compiled etags for Linux and
some other docs
<ftp://fly.isti.cnr.it/pub/software/unix/etags.tar.gz>.
patbuf is allocated in etags.c and
it looks like it's not fully initialized, but if this fix is right,
how could the code ever have worked?
At the time when the code you are using was written, the pattern buffer
did not include the external_to_internal_register member. As soon as
you run it with a new version of regex.c that included the new member,
it broke.
9:56 a.m.
>>>> "vin" == Vin Shelton <acs(a)xemacs.org>
writes:
vin> On my Solaris 5.8 machines here at work, when running 'make
vin> TAGS' with a 21.4.16 build, I'm getting a segv running etags.
vin> So, I set external_to_internal_register to 0 and the crash
vin> went away.
That looks right. In XEmacs proper, the patbuf is taken from a static
cache, so it will be initialized to all zeros. I forgot about etags
when I synched this from 21.4 to 21.5. :-(
vin> But, this can't be right, can it? patbuf is allocated in
vin> etags.c and it looks like it's not fully initialized, but if
vin> this fix is right, how could the code ever have worked?
In 21.4 etags.c, this is quite recently added code (post 21.4.15; to
fix the shy groups bug); maybe nobody's actually used etags.c with it.
In 21.5 etags.c, the whole pattern is explicitly cleared by setting it
to zeropattern.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7091
days inactive
7091
days old
3 comments
3 participants
participants (3)
-
Francesco Potorti` -
Stephen J. Turnbull -
Vin Shelton