Date: Sun, 16 May 1999 17:12:02 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Esa A E Peuha , djgpp AT delorie DOT com Subject: Re: An Emacs bug In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.)