bug#61514: 30.0.50; sadistically long xml line hangs emacs

[Stefan Monnier]

> The problem is in the combination of nxml-mode and some subtle
> bug/misfeature in our regexp routines.  Specifically, when we overflow
> the fail stack, we fail to recover in this case, and seem to infloop
> inside re_match_2_internal, or maybe recover very inefficiently (I
> waited for almost 1 hour before giving up).  The call which causes the
> loop is in xmltok.el, in the indicated line:
>
> (defun xmltok-scan-attributes ()
>   (let ((recovering nil)
>       (atts-needing-normalization nil))
>     (while (cond ((or (looking-at (xmltok-attribute regexp))
>                     ;; use non-greedy group
>                     (when (looking-at (concat "[^<>\n]+?"  <<<<<<<<<<<<<<<<<
>                                               (xmltok-attribute regexp)))
>                       (unless recovering
>                         (xmltok-add-error "Malformed attribute"
>                                           (point)
>                                           (save-excursion
>                                             (goto-char (xmltok-attribute start
>                                                                          
> name))
>                                             (skip-chars-backward "\r\n\t ")
>                                             (point))))
>                       t))
>
> The regexp that causes this is as follows:
>
>   
> "[^<>\n]+?\\(\\(?:\\(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]+\\)\\)\\)?"

IIUC the above describes the code where we're stuck inf-looping inside
`looking-at`?

Is it the same place where the regexp-stack overflow happens (and with
the same regexp)?


        Stefan