bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Nick Urbanik]

1. Start emacs with emacs -Q
2. Read in a large python file (3100 lines long, more than 10,000
    characters)
3. Near the top, type the following:

def function():
    """

4. No further input is accepted.
5. CPU usage is 100% as shown in /usr/bin/top
6. type kill -USR2 {process_id_of_emacs-Q}
    and the emacs window closes.
7. From my emacs started without '-Q', when I type
    killall -USR2 emacs
    I see:
Debugger entered--entering a function:
* #f(compiled-function () #<bytecode 0x8832586cc829512>)()
   syntax-ppss()
   python-nav-end-of-statement()
   python-nav-end-of-block()
   python-info-statement-ends-block-p()
   python-nav--forward-sexp(-1 nil nil)
   python-nav-forward-sexp(-1 nil nil)
   python-nav-backward-sexp()
   python-info-docstring-p((0 nil 2196 34 nil nil 0 nil 2211 nil nil))
   python-font-lock-syntactic-face-function((0 nil 2196 34 nil nil 0 nil 2211 nil nil))
   font-lock-fontify-syntactically-region(2028 3549 nil)
   font-lock-default-fontify-region(2028 3528 nil)
   font-lock-fontify-region(2028 3528)
   #f(compiled-function (fun) #<bytecode 0x19a2bc2905dba4bd>)(font-lock-fontify-region)
   jit-lock--run-functions(2028 3528)
   jit-lock-fontify-now(2028 3528)
   jit-lock-function(2028)
   redisplay_internal\ \(C\ function\)()



In GNU Emacs 28.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6)
  of 2023-01-28 built on buildvm-x86-04.iad2.fedoraproject.org
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Fedora Linux 37 (Workstation Edition)

Configured using:
  'configure --build=x86_64-redhat-linux-gnu
  --host=x86_64-redhat-linux-gnu --program-prefix=
  --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
  --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
  --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
  --libexecdir=/usr/libexec --localstatedir=/var
  --sharedstatedir=/var/lib --mandir=/usr/share/man
  --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
  --with-rsvg --with-tiff --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
  --with-xwidgets --with-modules --with-harfbuzz --with-cairo --with-json
  --with-native-compilation build_alias=x86_64-redhat-linux-gnu
  host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
  -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
  -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -Wp,-D_GLIBCXX_ASSERTIONS
  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
  -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
  LDFLAGS=-Wl,-z,relro
  PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
   value of $LANG: en_AU.utf8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Python

Minor modes in effect:
   yas-minor-mode: t
   highlight-indentation-mode: t
   company-mode: t
   elpy-mode: t
   pyvenv-mode: t
   flymake-mode: t
   global-auto-revert-mode: t
   display-time-mode: t
   shell-dirtrack-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t
   auto-fill-mode: t

Load-path shadows:
~/elisp/asn1-mode hides /home/nicku/.emacs.d/elpa/asn1-mode-20170729.226/asn1-mode
~/elisp/yaml-mode hides /home/nicku/.emacs.d/elpa/yaml-mode-20220903.1821/yaml-mode
/home/nicku/.emacs.d/elpa/dash-20220608.1931/dash hides /usr/share/emacs/site-lisp/dash/dash
/home/nicku/.emacs.d/elpa/s-20220902.1511/s hides /usr/share/emacs/site-lisp/s/s
/usr/share/emacs/site-lisp/goodies/emacs-goodies-loaddefs hides /usr/share/emacs/site-lisp/site-start.d/emacs-goodies-loaddefs
~/elisp/yaml-mode hides /usr/share/emacs/site-lisp/yaml-mode/yaml-mode
~/elisp/startup hides /usr/share/emacs/28.2/lisp/startup
/usr/share/emacs/site-lisp/rinari/util/jump/which-func hides /usr/share/emacs/28.2/lisp/progmodes/which-func
/usr/share/emacs/site-lisp/rinari/util/ruby-mode hides /usr/share/emacs/28.2/lisp/progmodes/ruby-mode

Features:
(shadow sort flyspell ispell mail-extr emacsbug message rmc puny rfc822
mml mml-sec epa epg rfc6068 epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils cl-print debug backtrace find-func dired-aux dired
dired-loaddefs misearch multi-isearch pylint company-oddmuse
company-keywords company-etags company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-template
company-cmake company-bbdb vc-git vc-dispatcher puppet-mode yasnippet
highlight-indentation company-capf company pcase help-fns radix-tree
elpy edmacro kmacro elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util elpy-shell
elpy-profile elpy-django s elpy-refactor diff-mode easy-mmode ido
hideshow grep etags fileloop generator xref cus-edit pp
graphviz-dot-mode use-package-ensure use-package-core finder-inf
yaml-mode generic-x server flymake-proc flymake project thingatpt post
moinmoin-mode erin jka-compr autorevert filenotify time cus-load
u-vm-color vm-autoloads comp comp-cstr warnings cl-extra help-mode
vm-version vm-vars preview-latex rx erlang-start epix derived info-look
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs rinari advice jump inflections findr ruby-compilation
which-func imenu inf-ruby compile text-property-search ruby-mode
emacs-goodies-loaddefs color-theme wid-edit cl cython-mode python
tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp
format-spec comint ring ansi-color clang-rename clang-include-fixer
let-alist clang-format xml bbdb-loaddefs auto-loads tex-site info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 543674 74632)
  (symbols 48 30193 3)
  (strings 32 142450 5048)
  (string-bytes 1 4349803)
  (vectors 16 64845)
  (vector-slots 8 1069734 41411)
  (floats 8 186 673)
  (intervals 56 9293 0)
  (buffers 992 32))

-- 
Nick Urbanik             http://nicku.org           nicku@nicku.org
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Eli Zaretskii]

> Date: Wed, 12 Apr 2023 17:05:13 +1000
> From: Nick Urbanik <nicku@nicku.org>
> 
> 
> 
> 1. Start emacs with emacs -Q
> 2. Read in a large python file (3100 lines long, more than 10,000
>     characters)

Thanks.

Please post such a file, or a URL where it could be downloaded.  I
couldn't easily find such a large file on my system.

> 3. Near the top, type the following:
> 
> def function():
>     """
> 
> 4. No further input is accepted.
> 5. CPU usage is 100% as shown in /usr/bin/top
> 6. type kill -USR2 {process_id_of_emacs-Q}
>     and the emacs window closes.
> 7. From my emacs started without '-Q', when I type
>     killall -USR2 emacs
>     I see:
> Debugger entered--entering a function:

I suspect this is already fixed in Emacs 29, but I cannot verify
without a file that reproduces the problem in Emacs 28.

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Nick Urbanik]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Dear Eli,

Thank you very much for your helpful and rapid response.  Emacs has
never let me down in daily use from 1993 till this problem came up.

On 12/04/23 18:39 +0300, Eli Zaretskii wrote:
>> Date: Wed, 12 Apr 2023 17:05:13 +1000
>> From: Nick Urbanik <nicku@nicku.org>
>>
>>
>>
>> 1. Start emacs with emacs -Q
>> 2. Read in a large python file (3100 lines long, more than 10,000
>>     characters)
>
>Thanks.
>
>Please post such a file, or a URL where it could be downloaded.  I
>couldn't easily find such a large file on my system.

It turns out that it is not the size, but some pathological
arrangement of the code.  I have provided a much smaller sample here
that I can reproduce the problem with by:

1. Move the cursor to below the from elesewhere import ... line.
2. Press Enter
3. Type:
def function():
     """

4. At this point, CPU usage goes to 100%, I cannot type anything else
into the buffer, but I can send a USR2 signal to end the 100% CPU
usage, but the buffer has only partial syntax colouring.
>
>> 3. Near the top, type the following:
>>
>> def function():
>>     """
>>
>> 4. No further input is accepted.
>> 5. CPU usage is 100% as shown in /usr/bin/top
>> 6. type kill -USR2 {process_id_of_emacs-Q}
>>     and the emacs window closes.
>> 7. From my emacs started without '-Q', when I type
>>     killall -USR2 emacs
>>     I see:
>> Debugger entered--entering a function:
>
>I suspect this is already fixed in Emacs 29, but I cannot verify
>without a file that reproduces the problem in Emacs 28.

I will build an RPM package of emacs 29 and test that.
-- 
Nick Urbanik             http://nicku.org           nicku@nicku.org
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24

[-- Attachment #2: head-a.py --]
[-- Type: text/plain, Size: 5302 bytes --]

#!/usr/bin/env python3

"""
This module aims to reproduce a bug in an emacs package.
"""

import time
import psycopg2
from elsewhere import error, warning, debug

class DB():
    """
    Under heavy network load, the connection to the database fails.
    Do not die then; reconnect.  Much of this code comes straight from
    https://gist.github.com/cabecada/da8913830960a644755b18a02b65e184
    """
    def __init__(self):
        self.conn = None
        self.cur = None
        self.user = 'Fred'
        self.pw = 'Secret of Fred'
        self.dbname = 'Database of Fred'
        self.limit_retries = 'Never give up, Fred.'
        self.host = 'Host of Fred'
        self.reconnect = True

    def connect(self, retries=0):
        """ Connect to the database with 5 second retries """
        if self.conn:
            return self.conn
        try:
            self.conn = psycopg2.connect(
                dbname=self.dbname,
                user=self.user,
                password=self.pw,
                host=self.host,
            )
            retries = 0
        except psycopg2.OperationalError as e:
            if not self.reconnect or retries >= self.limit_retries:
                error(f"CONNECTION FAIL: retries={retries}, "
                      f"reconnect={self.reconnect}: {e}")
                raise e

            retries += 1
            warning(f"Failure {e} connecting to {self.dbname}: retry {retries}")
            time.sleep(5)
            self.connect(retries)
        except Exception as e:
            raise Exception(f"Failed to connect to {self.dbname}: {e}")
        self.conn.set_session(autocommit=True)
        return self.conn

    def cursor(self):
        """ Try hard to provide a cursor into the database """
        if not self.cur or self.cur.closed:
            if not self.conn or self.conn.closed:
                self.connect()
            self.cur = self.conn.cursor()
        return self.cur

    def reset(self):
        """ If things went wrong, reconnect """
        self.close()
        self.connect()
        self.cursor()

    def close(self):
        """ We really need to close database connections to not run out. """
        if self.conn:
            if self.cur:
                self.cur.close()
            self.conn.close()
            debug("PostgreSQL connection is closed")
        self.conn = None
        self.cur = None

    def init(self):
        """ What we do when we start up """
        self.connect()
        self.cursor()

    def do(self, sql, values=None, many=False, num_rows=20):
        """
        Assumes the SQL is either an insert, delete or update.
        Assumes the SQL ends with the equivalent of: RETURNING pk,
        or perhaps: RETURNING pk1, pk2
        Returns a tuple containing the resulting value(s)
        even if the sql returns only one value.
        """
        if (values is not None
            and (not hasattr(values, '__len__') or isinstance(values, str))):
            values = (values,)

        for retry in range(1, self.limit_retries + 1):
            try:
                self.cur.execute(sql, values)
            except psycopg2.errors.UniqueViolation as e:
                # Then we are trying to insert something that already exists.
                debug(f"UNIQUE: Failed to do {sql} {values}: {e}")
                return None
            except (psycopg2.DatabaseError, psycopg2.OperationalError) as e:
                if retry >= self.limit_retries:
                    error(f"FAIL: retry={retry} for {sql} {values}: {e}")
                    raise e

                warning(f"Failure {str(e).strip()} doing {sql} {values}; "
                        f"retry {retry}")
                time.sleep(5)
                self.reset()
            except Exception as e:
                # Some other error that may result from a failed select
                # or any of the many other things that can go wrong.
                raise Exception(f"OTHER: Failed to do {sql} {values}: {e}")
            else:
                return (
                  self.cur.fetchmany(num_rows) if many else self.cur.fetchone()
                )
        return None

    def do_many(self, sql, values, num_rows=100):
        """
        Assumes the SQL is either an insert, delete or update.
        Assumes the SQL ends with the equivalent of: RETURNING pk,
        or perhaps: RETURNING pk1, pk2
        Returns a tuple of the resulting value
        even if the sql returns only one value.
        """
        return self.do(sql, values, True, num_rows)

    def exec_or_die(self, sql, values):
        """
        When we want to fail if the SQL doesn't work.
        """
        for retry in range(1, self.limit_retries + 1):
            try:
                self.cur.execute(sql, values)
            except (psycopg2.DatabaseError, psycopg2.OperationalError) as e:
                if retry >= self.limit_retries:
                    raise e

                warning(f"Failure {str(e).strip()} doing {sql} {values}; "
                        f"retry {retry}")
                time.sleep(1)
                self.reset()
            except Exception as e:
                raise Exception(f"Failed to do {sql} {values}: {e}")
            else:
                return self.cur
        return None

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Eli Zaretskii]

> Date: Thu, 13 Apr 2023 09:55:42 +1000
> From: Nick Urbanik <nicku@nicku.org>
> Cc: 62794@debbugs.gnu.org
> 
> >Please post such a file, or a URL where it could be downloaded.  I
> >couldn't easily find such a large file on my system.
> 
> It turns out that it is not the size, but some pathological
> arrangement of the code.  I have provided a much smaller sample here
> that I can reproduce the problem with by:
> 
> 1. Move the cursor to below the from elesewhere import ... line.
> 2. Press Enter
> 3. Type:
> def function():
>      """
> 
> 4. At this point, CPU usage goes to 100%, I cannot type anything else
> into the buffer, but I can send a USR2 signal to end the 100% CPU
> usage, but the buffer has only partial syntax colouring.

OK, thanks.  I can indeed reproduce this in Emacs 28.2, but not in
what soon will become Emacs 29.1.  So I think this problem was already
solved between these two version.

> >I suspect this is already fixed in Emacs 29, but I cannot verify
> >without a file that reproduces the problem in Emacs 28.
> 
> I will build an RPM package of emacs 29 and test that.

Thanks.  I will wait for your confirmation before closing the bug as
fixed.

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 13 Apr 2023 09:55:42 +1000
>> From: Nick Urbanik <nicku@nicku.org>
>> Cc: 62794@debbugs.gnu.org
>
> [...]
>
>> >I suspect this is already fixed in Emacs 29, but I cannot verify
>> >without a file that reproduces the problem in Emacs 28.
>
> [...]

A bit too late into the discussion, but I noticed that this is probably
a duplicate of bug#62325, which has been fixed for Emacs 29.

-- 
Best,


RY

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Nick Urbanik]

On 13/04/23 07:58 +0300, Eli Zaretskii wrote:
>> Date: Thu, 13 Apr 2023 09:55:42 +1000
>> From: Nick Urbanik <nicku@nicku.org>
>> Cc: 62794@debbugs.gnu.org
>>
>> >Please post such a file, or a URL where it could be downloaded.  I
>> >couldn't easily find such a large file on my system.
>>
>> It turns out that it is not the size, but some pathological
>> arrangement of the code.  I have provided a much smaller sample here
>> that I can reproduce the problem with by:
>>
>> 1. Move the cursor to below the from elesewhere import ... line.
>> 2. Press Enter
>> 3. Type:
>> def function():
>>      """
>>
>> 4. At this point, CPU usage goes to 100%, I cannot type anything else
>> into the buffer, but I can send a USR2 signal to end the 100% CPU
>> usage, but the buffer has only partial syntax colouring.
>
>OK, thanks.  I can indeed reproduce this in Emacs 28.2, but not in
>what soon will become Emacs 29.1.  So I think this problem was already
>solved between these two version.
>
>> >I suspect this is already fixed in Emacs 29, but I cannot verify
>> >without a file that reproduces the problem in Emacs 28.
>>
>> I will build an RPM package of emacs 29 and test that.
>
>Thanks.  I will wait for your confirmation before closing the bug as
>fixed.

I spent a couple of hours attempting to build an RPM package from git,
but each iteration takes a super long time, and I cannot afford to
spend a longer time from my work.  I may try again on the weekend.

For me this is a really big problem, as it has happened in other cases
of editing Python programs, and it is a big slowdown and interruption
to my workflow to restart emacs with lots of frames open.  Emacs has
always been so solid till this.

Fedora will not package emacs 29.1 before it is released.  I hope that
is soon.  F38 is due in 13 days, so this issue is likely to remain.

It would be fantastic to backport the fix.
-- 
Nick Urbanik             http://nicku.org           nicku@nicku.org
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Eli Zaretskii]

> Date: Thu, 13 Apr 2023 15:39:18 +1000
> From: Nick Urbanik <nicku@nicku.org>
> Cc: 62794@debbugs.gnu.org
> 
> >> I will build an RPM package of emacs 29 and test that.
> >
> >Thanks.  I will wait for your confirmation before closing the bug as
> >fixed.
> 
> I spent a couple of hours attempting to build an RPM package from git,
> but each iteration takes a super long time, and I cannot afford to
> spend a longer time from my work.  I may try again on the weekend.

Is it easier for you to try the pretest tarball?  If so, you can find
the pretest here:

  https://alpha.gnu.org/gnu/emacs/pretest/emacs-29.0.90.tar.xz

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Nick Urbanik]

On 13/04/23 09:01 +0300, Eli Zaretskii wrote:
>> Date: Thu, 13 Apr 2023 15:39:18 +1000
>> From: Nick Urbanik <nicku@nicku.org>
>> Cc: 62794@debbugs.gnu.org
>>
>> >> I will build an RPM package of emacs 29 and test that.
>> >
>> >Thanks.  I will wait for your confirmation before closing the bug as
>> >fixed.
>>
>> I spent a couple of hours attempting to build an RPM package from git,
>> but each iteration takes a super long time, and I cannot afford to
>> spend a longer time from my work.  I may try again on the weekend.
>
>Is it easier for you to try the pretest tarball?  If so, you can find
>the pretest here:
>
>  https://alpha.gnu.org/gnu/emacs/pretest/emacs-29.0.90.tar.xz

Thank you very much, Eli.  I successfully built an RPM under mock that
runs on Fedora 37 and am now free of that bug, and another that
prevented the formatting of docstrings.  Great, my faith in emacs is
restored, and I can continue to be productive with it.  My spec file
is here: https://nicku.org/software/#emacs-29.0

I pity all the other people stuck with 28.2 who work with Python and
who are plagued by this barrier to getting things done.
-- 
Nick Urbanik             http://nicku.org           nicku@nicku.org
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Eli Zaretskii]

> Date: Fri, 14 Apr 2023 16:02:59 +1000
> From: Nick Urbanik <nicku@nicku.org>
> Cc: 62794@debbugs.gnu.org
> 
> On 13/04/23 09:01 +0300, Eli Zaretskii wrote:
> >Is it easier for you to try the pretest tarball?  If so, you can find
> >the pretest here:
> >
> >  https://alpha.gnu.org/gnu/emacs/pretest/emacs-29.0.90.tar.xz
> 
> Thank you very much, Eli.  I successfully built an RPM under mock that
> runs on Fedora 37 and am now free of that bug, and another that
> prevented the formatting of docstrings.  Great, my faith in emacs is
> restored, and I can continue to be productive with it.  My spec file
> is here: https://nicku.org/software/#emacs-29.0
> 
> I pity all the other people stuck with 28.2 who work with Python and
> who are plagued by this barrier to getting things done.

Thanks for testing, I'm therefore closing this bug.

bug#62794: 28.2; jit-lock-function enters busy loop when open """ near top of large Python program

[Jim Porter]

On 4/12/2023 10:39 PM, Nick Urbanik wrote:
> For me this is a really big problem, as it has happened in other cases
> of editing Python programs, and it is a big slowdown and interruption
> to my workflow to restart emacs with lots of frames open.  Emacs has
> always been so solid till this.

You could try the python package available in GNU ELPA. It hasn't gotten 
an "official" release in a while, but the development archive has new 
versions: https://elpa.gnu.org/devel/python.html

This is the same code as what comes by default with an Emacs build. 
Maybe it would make sense to bump the version so that there's a new 
non-devel release on GNU ELPA. That way, anyone on an older Emacs can 
benefit from the fix for this issue.