Date:	Sun, 16 May 1999 17:12:02 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>, djgpp AT delorie DOT com
Subject:	Re: An Emacs bug
In-Reply-To:	<Pine.SUN.3.91.990516075725.57E-100000@is>
Message-ID:	<Pine.SUN.3.91.990516170037.20684B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 16 May 1999, I wrote:

> If the crash is with a traceback, please post it.

Forget it, I've reproduced the bug and looked into it.

As far as I could see, this bug is due to stack overflow in the regexp 
functions (called indirectly by `C-c C-d' when font-lock is ON).  It was
a known problem of Emacs 19 that certain packages defined too complex 
regular expressions, either for font-lock keywords, or for regexp-based 
search.  Since GNU regexp uses alloca for almost everything, that would 
sometimes overflow the stack, especially since the DJGPP version has only 
512KB of it (as opposed to other platforms where the stack is either 
dynamically resized or significantly larger).

I enlarged the stack to 4MB (with `stubedit') and the problem went away.  
So unless you are hard-pressed for run-time memory, this should be an 
easy work-around.

Emacs 20 doesn't have this problem, even with the default 512KB of stack. 
I think this is for two reasons: (1) the font-lock keywords in outline.el
were changed significantly since Emacs 19.34; and (2) the regexp package
now has built-in safeguards that use the actual run-time stack size and
throw an error when there's a danger of overflow.  (However, I didn't see
any errors thrown when I tried to reproduce the problem in Emacs 20, so
clearly this overflow protection is not the whole story.)

- Raw text -