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

Previous Next

Full log

View this message in rfc822 format

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

>> 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.
>
> If we know which regexps cause problems, shouldn't we instead fix those 
> regexps, or change how we use them?
>

If we know how and where to fix them, that's better of course.  If we 
don't (and frankly when I look at that regexp I have no idea how it could 
be fixed), limiting the backtracking depth to a more reasonable value is 
better than not fixing the bug.

>
> For debugging purposes, you can set the value in the debugger after 
> starting Emacs, or with a breakpoint just before calling the problematic 
> code.
>

That's only true for the (very) few of us who are comfortable building 
Emacs and running it under GDB (and even for them it's much easier to just 
change the value with a setq).  If regexp-max-backtracking-depth had been 
present, everyone could easily have tried to set it to some lower value.

Previous Next

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