From xemacs-m  Wed Sep 24 20:51:17 1997
Received: from dolphin.automatrix.com (dolphin.automatrix.com [198.69.29.254])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA11850
	for <xemacs-beta@xemacs.org>; Wed, 24 Sep 1997 20:51:16 -0500 (CDT)
Received: (from skip@localhost) by dolphin.automatrix.com (8.8.5/8.8.3) id VAA16659; Wed, 24 Sep 1997 21:51:19 -0400 (EDT)
Date: Wed, 24 Sep 1997 21:51:19 -0400 (EDT)
Message-Id: <199709250151.VAA16659@dolphin.automatrix.com>
From: Skip Montanaro <skip@calendar.com>
To: xemacs-beta@xemacs.org
Subject: More on XEmacs crashing in regex...
Reply-to: skip@calendar.com (Skip Montanaro)
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII


You may recall (though I suspect you're all ignoring me ;-) that regex is
bombing when trying to match re's on long lines.  I suspect the complexity
of the re has a lot to do with it.

At any rate, after a few false starts, I finally was able to figure out what
was going on (I think).  regex.c uses a lot of macros, so trying to figure
out what was happening required a fair amount of manual macro expansion.  At
certain points during execution, it tries to extend the size of the failure
stack.  Unfortunately, in my environment, it chooses to try and use alloca
to allocate (and reallocate) the stack.  Once it goes through a bunch of
stack resizes (it doubles on each resize), alloca returns an invalid pointer
(stack colliding with the heap?).  The line it bombs on is 5157 in regex.c
(I'm using 20.3 b22). It's trying to alloca 1310720 bytes, which means it
already has outgrown stacks of 655360, 327680, 163840, 81920, ... bytes, all
of which are still sitting on the stack (along with everything else).

I guess my alternative is to define REGEX_MALLOC and live with a little
(more) leakage.

Does this make sense to anyone?  Should some other allocation scheme be used
that provides a blend of the benefits of alloca and malloc?  Apache uses a
pool allocator.  It might allow leaks to be prevented if it's initialized
and released early enough, yet still allow the programmer to forget about
releasing storage most of the time.

Skip Montanaro     | Musi-Cal Express - get your own private Musi-Cal
skip@calendar.com  | domain name! http://concerts.calendar.com/express.shtml
(518)372-5583      | WebFast - http://www.webfast.com/

