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: 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 14:17:24 +0000
>>> 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.
>

In the current patch it is automatically capped to a maximum value.  It 
could also be automatically reset to a minimum value (say 1000 or 500 or 
100).  I just tried to set it to 500 in my configuration during a few 
minutes, and did not see any errors, so I don't see what could go 
fundamentally wrong if we give users control on that threshold.

It would have been much easier to debug this bug by asking Mark "could you 
please try to temporarily set regexp-max-backtracking-depth to 1000 and 
see if that fixes the bug?".  This bug report was easy to reproduce, so 
that wasn't necessary, but it would be for bug reports from users with 
more complex setup.





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.