bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56271: lisp/progmodes/python.el; unmatched quotes cause infinite loo


From: Tom Gillespie
Subject: bug#56271: lisp/progmodes/python.el; unmatched quotes cause infinite loop freezing emacs
Date: Mon, 27 Jun 2022 18:51:21 -0700

Using git bisect shows 85db21b94b23b4701930892d1eecc9a1167ed968 is the
source of this issue, all commits following it on master show the same
issue. Reverting that commit fixes the issue.

While editing python files if a single quote occurs in the file during
the course of editing then emacs will enter an infinite loop. The
exact location of the single quote is important, but the pattern that
triggers it happens frequently in python files.

You can get a traceback pinpointing the issue by sending SIGUSR2 to
the hung emacs process.

Below is a minimal python file that will trigger the issue.
Run with emacs -Q evil-python-file.py
#+begin_verbatim
def
    =''
 '
""""""
 # there must be at least one space on this line, comment not needed
''
#+end_verbatim

The full pattern that causes the issue is something like the following.

#+begin_verbatim
<keyword>
<exactly-python-indent-offset-number-of-spaces>=<zero-or-more-not-quotes>''
<at-least-one-space>'
<zero-or-more-lines-with-any-contents-except-single-quote-marks*>
<zero-or-more-spaces><triple-double-quote-string><any-but-single-quote>
<at-least-one-space><any-but-single-quote>
<single-quote-string>
#+end_verbatim

Any keyword should work I have tested with class, def, and with.

The zero or more lines at any indentation can also have single quote
marks that are paired, but there is some weirdness when you have 4 on
a line that makes it possible to avoid the issue.

I can fix the issue by reverting to the cl-assert pattern using unless
to raise an error (unless (>= string-start last-string-end) (error
"oops")) and running the code after that unconditionally. This
prevents jit-lock from trying to run infinitely on a malformed buffer.

That said, this may simply reintroduce bug#54996, and the change
unmasked some other issue with what is going on during the call to
jit-lock-function which needed that error to be throw by cl-assert to
avoid infinite loops/retries.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]