GNU bug report logs - #61514
30.0.50; sadistically long xml line hangs emacs

Previous Next

Full log

Message #92 received at 61514 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Mon, 20 Feb 2023 02:05:59 +0000

[Message part 1 (text/plain, inline)]

>> Lowering emacs_re_max_failures just makes the regexp engine fail 
>> earlier, because there is not enough room in the failure stack.  In a 
>> sense it is better to fail earlier, but to do that in all cases, we 
>> would have to lower emacs_re_max_failures say to 10000, which I guess 
>> wouldn't be good because the it would fail too much.
>
> BTW, this makes me wonder why emacs_re_max_failures is not accessible 
> from Elisp.  I think it would be very useful, if only for debugging 
> purposes. And perhaps let-binding it to a lower value around some 
> potentially (or actually) problematic regexps would be a good way to 
> prevent or fix bugs such as the current one.
>

Looking at the history of that variable, which is in fact a compile-time 
constant, I see that it was initially (May 1995) set to 200000.  A few 
months later (Nov 1995) it was set to 20000, and reduced again (apparently 
because of bug reports) to 8000 and to 4000 (both in Jun 1996).  Two 
months later it was again set to 20000 (Aug 1996), and a year later to 
40000 (Dec 1997).  It kept that value since then.  As these changes (and 
this bug report) demonstrate, it is not possible to give that variable a 
"one size fits all" value.

Here's a patch that makes it modifiable, and "fixes" (in the sense of 
failing with a "Stack overflow in regexp matcher" instead of inflooping) 
the current bug.

WDYT?

[Make-the-number-of-failure-points-in-regexp-searches.patch (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.