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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
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:37:51 -0500

>> The patch below fixes the stack overflow.
> Together with the "\\<" in xmltok.el, this fixes this bug indeed in all
> cases (truncated and non-truncated ones).  Congrats!

We probably still have an O(N²) behavior which can bite with a line like

   <id * name="N_N_N_N_N_N_N_N_.....">

My patch should significantly improve the constant factor, but with
a long enough "N_N_N_N_N..." I suspect it can still end up painful.

Maybe we should reduce the scope of the search for the fallback case
(the case where we add the "[^...]+\\<" prefix) since AFAICT its only
purpose is to try and guess a helpful error messages when the XML is
ill-formed.

>> I don't think we want that for `emacs-29`, but unless there's some
>> objection I'll push this to `master`,
> I'd say it fixes an important bug in the regexp engine, but I cannot judge
> whether it's important enough for emacs-29.

It's a missing optimization that's been with us for many many years, so
I don't see any urgency to fix it.


        Stefan

Previous Next

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