On Fri, 13 Dec 2002, Stephen J. Turnbull wrote:
In 21.4.10 and 21.4.11, trying to reply to Paul Krause's report,
I got
a crash in regex.c. For some reason when the number of failures gets
"big" (I'm not sure how big that is, I've not yet been able to watch
the crash in gdb), the local variable this_reg in PUSH_FAILURE_POINT
gets overwritten with (it seems) the value of the (static) global
variable fail_stack.size.
Just a note, this is exactly where OS X XEmacs 21.5.b9 fails on a number of
occasions. The only cure I found was to increase the stack, but it appears
when viewed through Apple's Project Developer that re_match_2 routines are
being called recursively (I counted 30 nested calls in one instance), and
the failure was always a bad memory access at the expression
PUSH_FAILURE_POINT (p1 + mcnt, d, -2);
So it looks like glibc's (2.3.1) alloca doesn't fail nicely?
Or maybe
GCC (2.95.4) is screwing up?
Compiling with -DREGEX_MALLOC "fixes".
Perhaps this would allow me to recompile with a smaller stack. An 8 MB
stack prevents the Carbonized program from being debugged in Project
Developer.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Dr. Robert D. Royar Morehead State University royar(a)adelphia.net
T r a f f i c expands to exceed the available roadway.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=