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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61514 <at> debbugs.gnu.org, mah <at> everybody.org
Subject: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Mon, 20 Feb 2023 14:24:09 +0000
>>> And for the stack overflow I haven't yet found its origin.
>>
>> There is no stack overflow here, AFAIU.  It's simply that the prepended 
>> regexp matches one or more (without any upper bound) characters except 
>> "<>\n", which means that we backtrack _a lot_ when the line is long.
>
> There is clearly a stack overflow since the OP showed stack overflow 
> errors in *Messages*.
>

Ah yes, I misunderstood what you meant.  I thought you were talking about 
a stack overflow bug in the regexp engine.

>
> And the stack overflow is in the rest of the regexp: the `+?` repetition 
> uses only ever 1 stack slot no matter how long a match we consider 
> (contrary to the `+` and `*` repetitions which use N stack slots for the 
> N repetitions of the longest match).
>

Indeed.  That's the bug in the bug.  But it's the '+?' repetition which 
causes the "infloop", right?





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.