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: Eli Zaretskii <eliz <at> gnu.org>
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 08:19:26 -0500

>> IIUC the above describes the code where we're stuck inf-looping inside
>> `looking-at`?
> Not inflooping, but very slowly backtracking, or so it seems.

Duh, right.  I meant "hang".  Sorry for being a bit mushy-brained for a moment.

>> Is it the same place where the regexp-stack overflow happens (and with
>> the same regexp)?
>
> It's (almost) the same place, but not the same regexp.  The regexp
> which causes the stack-overflow message (which is emitted from
> set-auto-mode, before entering redisplay) is this:
>
>   "\\(\\(?:\\(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 (not sure if it's the right
thing to do for all the regexp that can be returned by
`xmltok-attribute`, tho).

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


        Stefan

Previous Next

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