From: Tom Gillespie <tgbugs@gmail.com>
To: 56271@debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 54996@debbugs.gnu.org
Subject: bug#56271: lisp/progmodes/python.el; unmatched quotes cause infinite loop freezing emacs
Date: Mon, 27 Jun 2022 18:51:21 -0700 [thread overview]
Message-ID: <CA+G3_PMzbzK4W=Zrs+ksx0Z=vX1pp44aujC2z5+LmP_6bZc7eg@mail.gmail.com> (raw)
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.
next reply other threads:[~2022-06-28 1:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 1:51 Tom Gillespie [this message]
[not found] ` <87lethroiv.fsf@gnus.org>
[not found] ` <CA+G3_POGKF-fDfBuxNcc93WSEaaYzAd4FSgk-vKy=tQYOXYtHg@mail.gmail.com>
2022-06-29 2:45 ` bug#56271: lisp/progmodes/python.el; unmatched quotes cause infinite loop freezing emacs Tom Gillespie
2022-06-29 3:00 ` Tom Gillespie
2022-06-29 10:14 ` Lars Ingebrigtsen
2022-09-05 19:34 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+G3_PMzbzK4W=Zrs+ksx0Z=vX1pp44aujC2z5+LmP_6bZc7eg@mail.gmail.com' \
--to=tgbugs@gmail.com \
--cc=54996@debbugs.gnu.org \
--cc=56271@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).