1:32 p.m.
Version: 21.4
Build configuration: '--with-mule'; see `Installation' below
`re_search' when called by `string_match_1' may leave
`search_regs.end[1]' unchanged, even if it points beyond end of data
of STRING being searched in. My build with mule sometimes crashes on
such a values, when `fixup_search_regs_for_string' called by the same
`string_match_1' tries to process such an incorrect value and traverse
byte sequence that is not in mule internal coding.
Whether the crash will occur depends on data beyond string data bound,
and that can not be reproduced reliably. Incorrect
`search_regs.end[1]' value, however, reproduces even when evaluating
the following code.
(string-match "\\(a\\)" "..a")
(string-match "\\(b\\)" "c")
One should print `search_regs.end[1]' value:
. just after 1st `re_search' call;
. before 2nd `re_search' call, where it is the same;
. after 2nd `re_search' call, where it is the same.
--
`Installation' contents follows.
uname -a: Linux way2go 2.6.3-19mdk #1 Thu Sep 23 22:04:58 MDT 2004 i686 unknown unknown
GNU/Linux
../share/xemacs-local-21.4/configure '--prefix=/home/gin' '--cflags=-g -Wall
-Wno-switch -Wpointer-arith -Winline -Wmissing-prototypes -Wshadow'
'--cppflags=-DASSERTIONS_DONT_ABORT=1' '--with-gpm=no'
'--with-sound=native' '--with-pop' '--mail-locking=lockf'
'--with-clash-detection' '--debug' '--error-checking=all'
'--with-file-coding' '--with-mule' '--with-database=no'
'--with-hesiod=no' '--with-menubars=lucid'
'--with-scrollbars=lucid' '--with-dialogs=lucid' '--with-xim=xlib'
'--with-canna=no' '--with-wnn=no' '--with-wnn6=no'
'--with-msw=no' '--with-xfs=yes'
XEmacs 21.4.15 "Security Through Obscurity" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /home/gin/share/xemacs-local-21.4
Installation prefix: /home/gin
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -Wall -Wno-switch -Wpointer-arith -Winline
-Wmissing-prototypes -Wshadow
Compiler version: gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
Compiler specs file: /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.2/specs
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
libc: glibc-2.3.3-10mdk
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw
- Athena library to link: Xaw
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Compiling in support for NAS (network audio system).
Databases:
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: pgsql/libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for file coding.
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Mail:
Compiling in support for POP mail retrieval.
Compiling in support for "lockf" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new portable dumper.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
5:20 p.m.
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> `re_search' when called by `string_match_1' may leave
Ilya> `search_regs.end[1]' unchanged, even if it points beyond end
Ilya> of data of STRING being searched in. My build with mule
Ilya> sometimes crashes on such a values, when
Ilya> `fixup_search_regs_for_string' called by the same
Ilya> `string_match_1' tries to process such an incorrect value
Ilya> and traverse byte sequence that is not in mule internal
Ilya> coding.
I don't see how that can happen, offhand. I'll take a more careful
look later, but as far as I can see search_regs.end[i] should get
accessed only for registers that successfully matched in the current
search. Can you be more specific about where the offending access is?
Ilya> Whether the crash will occur depends on data beyond string
Ilya> data bound, and that can not be reproduced reliably.
Ilya> Incorrect `search_regs.end[1]' value, however, reproduces
Ilya> even when evaluating the following code.
This is irrelevant. First, there are no promises about the contents
of registers after an unsuccessful match, so "incorrect" is
inapplicable. Second and more important, the following code
(string-match "\\(a\\)" "..a")
(match-string 1 "c")
is legal and must not crash. So the code must be careful to check
bounds in strings here, and as far as I can tell it does. Certainly
the particular example above signals an error. Can you point more
specifically to the code that is causing the problem?
--
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.
8:32 p.m.
Can you be more specific about where the offending access is?
#0 fixup_search_regs_for_string ()
at search.c:279
#1 string_match_1 ()
at search.c:418
#2 Fstring_match ()
at search.c:435
as of revision 1.17.2.7 of that file. The value to be assigned there
is obtained by traversing string data up to byte `search_regs.end[i]',
requiring all the data to be in mule internal coding.
"incorrect" is
inapplicable.
Preceding text shows the meaning of "incorrect" in that phrase. And
certainly "inconsistent" is cleaner.
the following code
(string-match "\\(a\\)" "..a")
(match-string 1 "c")
is legal and must not crash.
Except explicit "decoding from mule internal coding" [1] of data that
are not in it, is there "illegal" elisp code that is allowed to crash?
As to the code above, it is irrelevant.
Certainly
the particular example above signals an error.
The trouble is not error signalled to / by elisp interpreter, but mule
internal coding data traversal failure. It occurs during computations
that are done always and set values that may or may not be requested
later by elisp through `match-string' call. It makes the entire
xemacs process non-functional, that is, crashes it, just as any other
mule internal coding traversal failure do.
That is, whether the traversal fails always depends on (potentially
random) memory contents. If built with `--error-checking' arg
including `typecheck', it manifests as assertion failure. Otherwise,
depending on memory contents, it may be memory (read) access violation
or infinite loop.
Footnotes.
[1] Implemented `#ifdef DEBUG_XEMACS' in 21.5. Why not in 21.4 do not
know. Why should it be worse than FSF that implements it by default?
8:32 p.m.
New subject: regexp match violates string bound [1]
Additional info. Built xemacs from
<ftp.sunet.se/pub/Linux/distributions/mandrakelinux/official/10.0/SRPMS/xemacs-21.4.14-2mdk.src.rpm>.
The only difference with default build settings was cflags that were
set to facilitate debugging. Observed the same setting
`search_regs.end[1]' past bound of data of string being searched in as
described in message posted to <xemacs-beta(a)xemacs.org> on Fri, 03 Dec
2004 16:32:10 +0300 (<028241b06ada11-gin(a)mo.msk.ru>).
7291
days inactive
7294
days old
3 comments
2 participants
participants (2)
-
Ilya N. Golubev -
Stephen J. Turnbull