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: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org
Subject: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Mon, 20 Feb 2023 15:54:52 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: mah <at> everybody.org,  61514 <at> debbugs.gnu.org
> Date: Mon, 20 Feb 2023 08:19:26 -0500
> 
> >   "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?"
> >
> > As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs"
> > makes all the difference.  So the looking-at which fails reasonably
> > quickly is the first call to looking-at above, whereas the one the
> > "hangs" is the second one.
> 
> Yes, it makes a lot of sense now.
> 
> > Maybe this points out a way out of this misery?
> 
> I think it does.  E.g. there's a chance that using "[^<>\n]+?\\<"
> instead of "[^<>\n]+?"  avoids the hang

It does, thanks.

> (not sure if it's the right thing to do for all the regexp that can
> be returned by `xmltok-attribute`, tho).

How would we go about finding out?  Because other than that, changing
the regexp solves this nasty problem, and all the tests in
test/lisp/nxml/ still pass.

> And for the stack overflow I haven't yet found its origin.

Not sure what is the mystery here.  AFAIU, we look for the closing
">", don't find it, and then start looking for fewer and fewer non-'>'
characters followed by '>'.  Isn't that what happens here?

Previous Next

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