7:24 p.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
In XEmacs 21.2 (beta35) "Nike" [Lucid] (i686-pc-linux) of Sun Jul 23 2000 on
sauna.ton.tut.fi
configured using `configure --cache-file=/dev/null --with-dialogs=athena
--prefix=/opt/local'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
eval
(string-match "\\(\\.\\=\\)" ".")
This problem does not seem to be affected by OS version, also it
is present when compiled with gcc 2.95.2 and latest snapshot. I
see this also when I compile without optimisations (-O0). I
don't know which version first has the problem. But version I
currently use 21.1.4 does not die in this assert and outputs
'nil'. There does not seem to be any difference between
'-vanilla' and using my normal .emacs.
I guess this can be tested by others with following patch.
Index: tests/automated/lisp-tests.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-20/tests/automated/Attic/lisp-tests.el,v
retrieving revision 1.1.2.12
diff -u -r1.1.2.12 lisp-tests.el
--- lisp-tests.el 2000/02/13 10:29:26 1.1.2.12
+++ lisp-tests.el 2000/07/23 18:23:40
＠＠ -831,6 +831,8 ＠＠
(Assert (equal (split-string "foo,,bar" ",+") '("foo"
"bar")))
(Assert (equal (split-string ",foo,,bar," ",+") '(""
"foo" "bar" "")))
+(Assert (not (string-match "\\(\\.\\=\\)" ".")))
+
;;-----------------------------------------------------
;; Test near-text buffer functions.
;;-----------------------------------------------------
Recent keystrokes:
misc-user
Recent messages (most recent first):
Loading footnote...
Loading emacsbug...done
Loading emacsbug...
Loading time...done
Loading time...
Loading /home/maage/xemacs/options.el...done
Loading font...done
Loading font...
`where-was-i-db' enabled.
Loading where-was-i-db...done
Fatal error: assertion failed, file /usr/src/xemacs/xemacs_21_2/src/insdel.c, line 1122, (
x) >= BI_BUF_BEG (buf) && x <= BI_BUF_Z (buf)
Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
If you have access to the PROBLEMS file that came with your
version of XEmacs, please check to see if your crash is described
there, as there may be a workaround available.
Otherwise, please report this bug by running the send-pr
script included with XEmacs, or selecting `Send Bug Report'
from the help menu.
As a last resort send ordinary email to `crashes(a)xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type
gdb /usr/src/xemacs_21_2.build/src/xemacs core
then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB. A similar procedure should work for all of
these. Ask your system administrator if you need more help.)
Lisp backtrace follows:
string-match("\\(\\.\\=\\)" ".")
eval((string-match "\\(\\.\\=\\)" "."))
# bind (eval-expression-insert-value expression)
#<compiled-function (expression &optional eval-expression-insert-value)
"...(18)" [eval expression values prin1 eval-expression-insert-value t] 3 767078
(list (read-from-minibuffer "Eval: " nil read-expression-map t ...)
current-prefix-arg)>((string-match "\\(\\.\\=\\)" ".") nil)
call-interactively(eval-expression)
# (condition-case ... . error)
# (catch top-level ...)
zsh: 6219 abort (core dumped) ./src/xemacs
#0 0x40376d41 in __kill () from /lib/libc.so.6
(gdb) where
#0 0x40376d41 in __kill () from /lib/libc.so.6
#1 0x80b7084 in fatal_error_signal (sig=6)
at /usr/src/xemacs/xemacs_21_2/src/emacs.c:514
#2 0x40376c68 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#3 0x403780d8 in abort () at ../sysdeps/generic/abort.c:88
#4 0x80b9f15 in assert_failed (
file=0x8265f20 "/usr/src/xemacs/xemacs_21_2/src/insdel.c", line=1122,
expr=0x8265fa0 "( x) >= BI_BUF_BEG (buf) && x <= BI_BUF_Z
(buf)")
at /usr/src/xemacs/xemacs_21_2/src/emacs.c:3118
#5 0x81669f4 in bytind_to_bufpos (buf=0x8320b78, x=1688246)
at /usr/src/xemacs/xemacs_21_2/src/insdel.c:1122
#6 0x81b07a2 in re_match_2_internal (bufp=0x82aa8d0, string1=0x0, size1=0,
string2=0x89fe10c ".", size2=1, pos=0, regs=0x82ab934, stop=1)
at /usr/src/xemacs/xemacs_21_2/src/regex.c:5511
#7 0x81ac796 in sys_re_search_2 (bufp=0x82aa8d0, string1=0x0, size1=0,
string2=0x89fe10c ".", size2=1, startpos=0, range=1, regs=0x82ab934,
stop=1) at /usr/src/xemacs/xemacs_21_2/src/regex.c:4074
#8 0x81b11b8 in sys_re_search (bufp=0x82aa8d0, string=0x89fe10c ".", size=1,
startpos=0, range=1, regs=0x82ab934)
at /usr/src/xemacs/xemacs_21_2/src/regex.c:3865
#9 0x81b1c23 in string_match_1 (regexp=143985756, string=143985772,
start=137233100, buf=0x8320b78, posix=0)
at /usr/src/xemacs/xemacs_21_2/src/search.c:397
#10 0x81b5c8e in Fstring_match (regexp=143985756, string=143985772,
start=137233100, buffer=137233100)
at /usr/src/xemacs/xemacs_21_2/src/search.c:420
#11 0x80bea04 in Feval (form=144168028)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:3014
#12 0x80bf348 in Ffuncall (nargs=2, args=0xbfffea04)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:3214
#13 0x80937db in execute_optimized_program (
program=0x8a4bab8 "=c0\t!\nB\022=c3\n＠\f=ab\004p=aa\002=c5\"\207",
stack_depth=3,
constants_data=0x83e9bf8) at /usr/src/xemacs/xemacs_21_2/src/bytecode.c:745
#14 0x809339c in funcall_compiled_function (fun=138297216, nargs=2,
args=0xbfffeb64) at /usr/src/xemacs/xemacs_21_2/src/bytecode.c:517
#15 0x80bf4d0 in Ffuncall (nargs=3, args=0xbfffeb60)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:3249
#16 0x80bfb8c in Fapply (nargs=2, args=0xbfffebe8)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:3486
#17 0x80c27c7 in apply1 (fn=138297216, arg=143760960)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:3839
#18 0x809755e in Fcall_interactively (function=138318956,
record_flag=137233100, keys=137233100)
at /usr/src/xemacs/xemacs_21_2/src/callint.c:394
#19 0x80bddc6 in Fcommand_execute (cmd=138318956, record=137233100,
keys=137233100) at /usr/src/xemacs/xemacs_21_2/src/eval.c:2652
#20 0x80fc42c in execute_command_event (command_builder=0x836ee70,
event=141870892) at /usr/src/xemacs/xemacs_21_2/src/event-stream.c:3838
#21 0x80fcfef in Fdispatch_event (event=144687836)
at /usr/src/xemacs/xemacs_21_2/src/event-stream.c:4157
#22 0x809da85 in Fcommand_loop_1 ()
at /usr/src/xemacs/xemacs_21_2/src/cmdloop.c:579
#23 0x80bc2d4 in condition_case_1 (handlers=137233196,
bfun=0x809dcc0 <command_loop_1>, barg=137233100,
hfun=0x809dd80 <cmd_error>, harg=137233100)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:1640
#24 0x809df76 in command_loop_2 (dummy=137233100)
at /usr/src/xemacs/xemacs_21_2/src/cmdloop.c:256
#25 0x80bc0cc in internal_catch (tag=137304860,
func=0x809df30 <command_loop_2>, arg=137233100, threw=0x0)
at /usr/src/xemacs/xemacs_21_2/src/eval.c:1306
#26 0x809d23e in initial_command_loop (load_me=137233100)
at /usr/src/xemacs/xemacs_21_2/src/cmdloop.c:305
#27 0x80b80d5 in xemacs_21_2_b35_i686_pc_linux ()
at /usr/src/xemacs/xemacs_21_2/src/emacs.c:2155
#28 0x80b8914 in main () at /usr/src/xemacs/xemacs_21_2/src/emacs.c:2584
#29 0x403709cb in __libc_start_main (main=0x80b8810 <main>, argc=1,
argv=0xbffff254, init=0x807e500 <_init>, fini=0x822093c <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff24c)
at ../sysdeps/generic/libc-start.c:92
--
//Markus
9:24 a.m.
Markus Linnala <maage(a)cs.tut.fi> writes:
eval
(string-match "\\(\\.\\=\\)" ".")
The crash is caused by buffer bound checking code. When
matching against string, pointer d in re_match_2_internal
does not point to a string inside the buffer.
BI_BUF_PTR_BYTE_POS returns right value only when d points
inside the buffer.
This patch checks if the value is reasonable so that assert
won't be hit. I'm not so good at this regexp stuff, so I'd
appreciate it very much if someone comes up with a better
fix.
I guess this can be tested by others with following patch.
Index: tests/automated/lisp-tests.el
Thanks. I've applied it to the sources.
2000-08-03 Yoshiki Hayashi <yoshiki(a)xemacs.org>
* regex.c (re_match_2_internal): Check if pointer is inside
a buffer so that assert won't be triggered when matching against
strings.
* buffer.h (VALID_BUF_PTR_P): New macro.
Index: buffer.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/buffer.h,v
retrieving revision 1.13.2.21
diff -u -r1.13.2.21 buffer.h
--- buffer.h 2000/07/21 10:15:48 1.13.2.21
+++ buffer.h 2000/08/03 08:23:44
＠＠ -636,6 +636,9 ＠＠
#define BUF_PTR_BYTE_POS(buf, ptr) \
bytind_to_bufpos (buf, BI_BUF_PTR_BYTE_POS (buf, ptr))
+#define VALID_BUF_PTR_P(buf, ptr) \
+ valid_memind_p (buf, bytind_to_memind (buf, BI_BUF_PTR_BYTE_POS (buf, ptr)))
+
/* Address of byte at position POS in buffer. */
INLINE_HEADER Bufbyte * BI_BUF_BYTE_ADDRESS (struct buffer *buf, Bytind pos);
INLINE_HEADER Bufbyte *
Index: regex.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/regex.c,v
retrieving revision 1.22.2.6
diff -u -r1.22.2.6 regex.c
--- regex.c 2000/03/13 07:28:04 1.22.2.6
+++ regex.c 2000/08/03 08:23:45
＠＠ -5500,21 +5500,24 ＠＠
#ifdef emacs
case before_dot:
DEBUG_PRINT1 ("EXECUTING before_dot.\n");
- if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d) >=
- BUF_PT (regex_emacs_buffer))
+ if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
+ || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
+ >= BUF_PT (regex_emacs_buffer))
goto fail;
break;
case at_dot:
DEBUG_PRINT1 ("EXECUTING at_dot.\n");
- if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
+ if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
+ || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
!= BUF_PT (regex_emacs_buffer))
goto fail;
break;
case after_dot:
DEBUG_PRINT1 ("EXECUTING after_dot.\n");
- if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
+ if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
+ || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
<= BUF_PT (regex_emacs_buffer))
goto fail;
break;
--
Yoshiki Hayashi
12:13 p.m.
Unfortunately, I get crashes with this regexp now in the test suite.
Things like this happen:
Testing /project/xemacs/ws/bsd/tests/automated/lisp-tests.el...Fatal error: assertion
failed, file /project/xemacs/ws/bsd/src/insdel.c, line 1122, ( x) >= BI_BUF_BEG (buf)
&& x <= BI_BUF_Z (buf)
Fatal error (6).
[...]
Lisp backtrace follows:
string-match("\\(\\.\\=\\)" ".")
(not (string-match "\\(\\.\\=\\)" "."))
[...]
This happens for me on more than one platform, with and without mule,
but only if I build with error-checking.
Yoshiki, if you cannot reproduce this, you can get access to my own
workspaces.
Ben, you are the most knowledgable regexp maintainer here. Can you
take a look at this?
Yoshiki, also make sure that any fix does not involve "hiding" the bug
by changing asserts, etc...
>>>> "Y" == Yoshiki Hayashi
<yoshiki(a)xemacs.org> writes:
Y> Markus Linnala <maage(a)cs.tut.fi> writes:
> eval
> (string-match "\\(\\.\\=\\)" ".")
Y> The crash is caused by buffer bound checking code. When
Y> matching against string, pointer d in re_match_2_internal
Y> does not point to a string inside the buffer.
Y> BI_BUF_PTR_BYTE_POS returns right value only when d points
Y> inside the buffer.
Y> This patch checks if the value is reasonable so that assert
Y> won't be hit. I'm not so good at this regexp stuff, so I'd
Y> appreciate it very much if someone comes up with a better
Y> fix.
> I guess this can be tested by others with following patch.
>
> Index: tests/automated/lisp-tests.el
Y> Thanks. I've applied it to the sources.
Y> 2000-08-03 Yoshiki Hayashi <yoshiki(a)xemacs.org>
Y> * regex.c (re_match_2_internal): Check if pointer is inside
Y> a buffer so that assert won't be triggered when matching against
Y> strings.
Y> * buffer.h (VALID_BUF_PTR_P): New macro.
Y> Index: buffer.h
Y> ===================================================================
Y> RCS file: /usr/CVSroot/XEmacs/xemacs/src/buffer.h,v
Y> retrieving revision 1.13.2.21
Y> diff -u -r1.13.2.21 buffer.h
Y> --- buffer.h 2000/07/21 10:15:48 1.13.2.21
Y> +++ buffer.h 2000/08/03 08:23:44
Y> ＠＠ -636,6 +636,9 ＠＠
Y> #define BUF_PTR_BYTE_POS(buf, ptr) \
Y> bytind_to_bufpos (buf, BI_BUF_PTR_BYTE_POS (buf, ptr))
Y> +#define VALID_BUF_PTR_P(buf, ptr) \
Y> + valid_memind_p (buf, bytind_to_memind (buf, BI_BUF_PTR_BYTE_POS (buf, ptr)))
Y> +
Y> /* Address of byte at position POS in buffer. */
Y> INLINE_HEADER Bufbyte * BI_BUF_BYTE_ADDRESS (struct buffer *buf, Bytind pos);
Y> INLINE_HEADER Bufbyte *
Y> Index: regex.c
Y> ===================================================================
Y> RCS file: /usr/CVSroot/XEmacs/xemacs/src/regex.c,v
Y> retrieving revision 1.22.2.6
Y> diff -u -r1.22.2.6 regex.c
Y> --- regex.c 2000/03/13 07:28:04 1.22.2.6
Y> +++ regex.c 2000/08/03 08:23:45
Y> ＠＠ -5500,21 +5500,24 ＠＠
Y> #ifdef emacs
Y> case before_dot:
Y> DEBUG_PRINT1 ("EXECUTING before_dot.\n");
Y> - if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d) >=
Y> - BUF_PT (regex_emacs_buffer))
Y> + if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
Y> + || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
Y> + >= BUF_PT (regex_emacs_buffer))
Y> goto fail;
Y> break;
Y> case at_dot:
Y> DEBUG_PRINT1 ("EXECUTING at_dot.\n");
Y> - if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
Y> + if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
Y> + || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
Y> != BUF_PT (regex_emacs_buffer))
Y> goto fail;
Y> break;
Y> case after_dot:
Y> DEBUG_PRINT1 ("EXECUTING after_dot.\n");
Y> - if (BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
Y> + if (!VALID_BUF_PTR_P (regex_emacs_buffer, (unsigned char *) d)
Y> + || BUF_PTR_BYTE_POS (regex_emacs_buffer, (unsigned char *) d)
Y> <= BUF_PT (regex_emacs_buffer))
Y> goto fail;
Y> break;
Y> --
Y> Yoshiki Hayashi
12:32 p.m.
Martin Buchholz <martin(a)xemacs.org> writes:
Lisp backtrace follows:
string-match("\\(\\.\\=\\)" ".")
(not (string-match "\\(\\.\\=\\)" "."))
[...]
This happens for me on more than one platform, with and without mule,
but only if I build with error-checking.
Yoshiki, if you cannot reproduce this, you can get access to my own
workspaces.
I can. And my patch supposed fix the crash but I didn't
apply it while I was in Tokyo. I'd like to apply it after
the discussion is over.
Ben, you are the most knowledgable regexp maintainer here. Can you
take a look at this?
Yoshiki, also make sure that any fix does not involve "hiding" the bug
by changing asserts, etc...
No, it doesn't change asserts. In this case, the assert is
too aggressive. The same routine is called by (looking-at
"\\=") and (string-match "\\=" ""). It you do
string-match,
new string is allocated somewhere outside Lisp buffer. So
you need to check whether you are matching against Lisp
string or Lisp buffer. I first thought adding new argument
is easy and right solution but regex.c provides POSIX
interface and I can't change it. You can create a global
variable but I'm reluctant to introduce new grobal
variables. Global variables makes things more complicated.
If you can't distingush it, then you must not assert because
it is a valid value. It might hide one bug, though. If you
match against Lisp buffer and somehow it does not end up
inside the buffer, it won't hit assert.
So the question is, do you want to create a global variable
or not? Any comments are welcome.
--
Yoshiki Hayashi
11:55 p.m.
according to the xemacs docs,
`\='
matches the empty string, but only at point. (This construct is
not defined when matching against a string.)
i think that "not defined" in this case means simply ignore the \=.
we already have a global var regex_emacs_buffer. when we are matching a string,
it makes no sense at all to compare the string pointer with the buffer. so we
should add a global var regex_emacs_buffer_p indicating whether we are matching
a buffer, and if not, just do nothing when we encounter these constructs. your
addition of VALID_BUF_PTR_P is not correct.
Yoshiki Hayashi wrote:
Martin Buchholz <martin(a)xemacs.org> writes:
> Lisp backtrace follows:
>
> string-match("\\(\\.\\=\\)" ".")
> (not (string-match "\\(\\.\\=\\)" "."))
> [...]
>
> This happens for me on more than one platform, with and without mule,
> but only if I build with error-checking.
>
> Yoshiki, if you cannot reproduce this, you can get access to my own
> workspaces.
I can. And my patch supposed fix the crash but I didn't
apply it while I was in Tokyo. I'd like to apply it after
the discussion is over.
> Ben, you are the most knowledgable regexp maintainer here. Can you
> take a look at this?
>
> Yoshiki, also make sure that any fix does not involve "hiding" the bug
> by changing asserts, etc...
No, it doesn't change asserts. In this case, the assert is
too aggressive. The same routine is called by (looking-at
"\\=") and (string-match "\\=" ""). It you do
string-match,
new string is allocated somewhere outside Lisp buffer. So
you need to check whether you are matching against Lisp
string or Lisp buffer. I first thought adding new argument
is easy and right solution but regex.c provides POSIX
interface and I can't change it. You can create a global
variable but I'm reluctant to introduce new grobal
variables. Global variables makes things more complicated.
If you can't distingush it, then you must not assert because
it is a valid value. It might hide one bug, though. If you
match against Lisp buffer and somehow it does not end up
inside the buffer, it won't hit assert.
So the question is, do you want to create a global variable
or not? Any comments are welcome.
--
Yoshiki Hayashi
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/
3:37 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> according to the xemacs docs,
Ben> `\='
Ben> matches the empty string, but only at point. (This construct
Ben> is not defined when matching against a string.)
Ben> i think that "not defined" in this case means simply ignore
Ben> the \=.
In many contexts, "X is not defined in context Y" is equivalent to "it
is an error to use X in context Y (but the system may or may not
signal the error)".
I think `"\=" never matches a string' is a _plausible_ interpretation
of the construct in this context; I think it's a good candidate for
correct, too. Whichever you choose (I haven't thought carefully, I
don't really care) make sure the documentation is fixed to reflect the
implementation accurately. "Not defined" is ambiguous.
--
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."
8872
days inactive
8888
days old
5 comments
5 participants
participants (5)
-
Ben Wing -
Markus Linnala -
Martin Buchholz -
Stephen J. Turnbull -
Yoshiki Hayashi