bug#59408: closed (Emacs infinitely load when opening .py file)

[GNU bug Tracking System]

Your message dated Sun, 20 Nov 2022 19:17:08 +0200
with message-id <831qpx5ywb.fsf@gnu.org>
and subject line Re: bug#59408: Emacs infinitely load when opening .py file
has caused the debbugs.gnu.org bug report #59408,
regarding Emacs infinitely load when opening .py file
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
59408: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59408
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Emacs infinitely load when opening .py file Date: Sun, 20 Nov 2022 05:35:34 -0500

# Description of the bug

I've attached a file named "main.py". I've tried opening it with
"emacs -Q main.py" in a tty and Emacs infinitely loads.

# Reproducing the bug

1. Open the file I've attached in this message with "emacs -Q main.py".

At this point, Emacs will infinitely load (at least that's what I can
infer since I waited 30 seconds and then decided to kill the process)

# Additional information

I noticed a sudden increase in the usage of my CPU (because of the
sound that my computer produced), so I executed the following command
to see which processes were using more CPU resources.

```
$ watch -n 0.5 -d "ps -e -o tname,pid,%cpu,args | sort -nk3 | tail"
```

The following are the three last lines of the command that is being watched.

```
pts/0      15153  6.9 /usr/lib/firefox/firefox
?          14687  8.4 emacs --daemon -f exwm-enable
tty4       39122 98.5 emacs -Q main.py
```

As you can see above, the Emacs process that is opening that file is
using the most of the CPU.

It's worth mentioning that the attached file is a simplified version
of the file that I was editing. When I first found this bug, I was
editing a .py file with more lines and I found this infinite loading
when I executed M-x occur and searched for any string. Fortunately, I
was able to cancel the infinite loading with C-g, so I used the
profiler-* functions to see what was causing this unexpected behavior.
The attached files named profiler-report-cpu.txt and
profiler-report-memory.txt contain the output of profiler-report. As
you can see in the output of those reports, syntax-ppss is the last
function that is shown as a function that is using more than 80% of
memory and CPU. Recall that I mentioned that I pressed C-g to cancel
the infinite loading, that's the reason why other functions are shown
below with 0% usage of cpu and memory.

# System information

I'm using Emacs 28.2 in Arch Linux (see proof below).

```
$ emacs --version
GNU Emacs 28.2
Copyright (C) 2022 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
```

profiler-report-cpu.txt
Description: Text document

main.py
Description: Text Data

profiler-report-memory.txt
Description: Text document

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#59408: Emacs infinitely load when opening .py file
>
>
>
>
> Date: 
>
> Sun, 20 Nov 2022 19:17:08 +0200
>
>
>
>
> > From: Rodrigo Morales <moralesrodrigo1100@gmail.com>
> > Date: Sun, 20 Nov 2022 11:49:15 -0500
> > Cc: 59408@debbugs.gnu.org
> > 
> > > Can you try the master branch of the Emacs Git repository, and see if
> > > your actual Python file loads reasonably fast with Emacs 29?
> > 
> > Done. I compiled Emacs from master branch, and I didn't find that
> > issue when opening my actual Python file, so, as you said, it seems
> > that the problem has been fixed in Emacs 29.
> > 
> > For the record, I compiled Emacs from the commit shown below (last
> > commit in master branch as of the time of this writing)
> > 
> > ```
> > $ git log -n 1
> > commit 8874cd908c0ea0e2200f6f4f596bf645e76a0c0c (HEAD -> master, 
> > origin/master, origin/HEAD)
> > Author: Po Lu <luangruo@yahoo.com>
> > Date:   Sun Nov 20 21:01:10 2022 +0800
>
> Great, thanks for testing.  I'm therefore closing this bug.
>
>
> --- End Message ---