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

Previous Next

Package: emacs;

Reported by: "Mark A. Hershberger" <mah <at> everybody.org>

Date: Tue, 14 Feb 2023 21:05:02 UTC

Severity: normal

Found in version 30.0.50

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.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 15:14:07 +0200
> Date: Mon, 20 Feb 2023 12:40:54 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> >> 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.

So let's try fixing the issue that way first, and only fall back to
"limiting failures" if we decide we failed with that.

> > 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.

I don't trust people who don't build Emacs and run it under GDB to use
such a variable judiciously.




This bug report was last modified 2 years and 147 days ago.

Previous Next


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