Bug 2187041 - jit-lock-function enters busy loop when open """ near top of some python programs
Summary: jit-lock-function enters busy loop when open """ near top of some python prog...
Keywords:
Status: CLOSED COMPLETED
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 37
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-16 04:53 UTC by Nick Urbanik
Modified: 2023-10-06 04:25 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-05 13:43:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
This program can reproduce the bug reliably. (5.18 KB, text/x-python3)
2023-04-16 04:53 UTC, Nick Urbanik
no flags Details
upstream fix (3.78 KB, application/mbox)
2023-05-27 19:05 UTC, Chemal Pemail
no flags Details

Description Nick Urbanik 2023-04-16 04:53:41 UTC
Created attachment 1957649 [details]
This program can reproduce the bug reliably.

Description of problem:
When editing some Python programs, emacs enters a busy loop becoming unresponsive when opening a docstring for a function.


Version-Release number of selected component (if applicable): 28.2-3


How reproducible: With particular python files, completely.


Steps to Reproduce:
1. Edit the file head-a.py (provided attached to this bug) with emacs -Q.
2. After the line, "from elsewhere import error, warning, debug", enter:

def function()
    """
3. /usr/bin/top shows emacs going to 100%, and you cannot enter any text into emacs until you send it a USR2 signal, when you see the lisp debugger show:
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\)()

Actual results: emacs becomes unresponsive and consumes 100% CPU.


Expected results: emacs should allow me to insert a docstring into the function and continue editing.


Additional info: Bug filed upstream at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62794

*** DOES NOT HAPPEN IN emacs 29.0 ***

Comment 1 Nick Urbanik 2023-04-16 08:34:30 UTC
This persists in Fedora 38.  It has been the most serious bug I have encountered in my daily use of emacs since 1993, in terms of my productivity; after closing all the frames, I need to waste much time to reorientate myself.

Please consider upgrading to a pre-release version of emacs to fix this, or backport a fix to version 28.x.

Comment 2 Chemal Pemail 2023-05-27 19:04:37 UTC
Upstream fix is here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58780

Attached as it works for 28.2 too.

Comment 3 Chemal Pemail 2023-05-27 19:05:32 UTC
Created attachment 1967347 [details]
upstream fix

Comment 4 Benson Muite 2023-05-28 06:29:05 UTC
Thanks for reporting this and also reporting the fix.

Comment 5 Benson Muite 2023-05-31 06:15:56 UTC
Nick and Chemal, thanks for the fix.  Have created a pull request:
https://src.fedoraproject.org/rpms/emacs/pull-request/26
Perhaps you might also be interested in helping maintain this package?

Upgrading to the alpha release seems reasonable:
https://alpha.gnu.org/pub/gnu/emacs/pretest/
But may take a more careful rebuild so have not done that yet.

Comment 6 Benson Muite 2023-05-31 07:49:12 UTC
Merged for rawhide. Will test on f38 and f37 later today and then merge if all is ok.

Comment 7 Benson Muite 2023-06-05 13:43:11 UTC
Have merged patch in F38. F37 should complete soon. Please re-open if any issues.

Comment 8 Chemal Pemail 2023-06-06 05:22:14 UTC
(In reply to Benson Muite from comment #5)
> Nick and Chemal, thanks for the fix.  Have created a pull request:
> https://src.fedoraproject.org/rpms/emacs/pull-request/26
> Perhaps you might also be interested in helping maintain this package?

Actually I don't use fedora directly. I'm only building rpms for RHEL derived from the fedora source rpm at https://copr.fedorainfracloud.org/coprs/mlampe/emacs-28.

Comment 9 Benson Muite 2023-06-06 10:53:22 UTC
Thanks. Would Emacs in EPEL be helpful for you? What you have in Copr carries additional patches that are not in Fedora, and maybe useful.

Comment 10 Chemal Pemail 2023-06-06 13:23:23 UTC
Emacs is already in RHEL, hence EPEL will not package a newer version.

I have added RH's patches for four recent CVEs they considered important enough to fix for el8 and el9:
1) Fix etags local command injection vulnerability (#2184369)
2) Fix htmlfontify.el command injection vulnerability (#2184368)
3) Fix ruby-mode.el local command injection vulnerability (#2184367)
4) Fix ob-latex.el command injection vulnerability (#2180585)

These bugs are not public, but 2) should be equivalent to #2171990, 3) to #2171991, and 4) to #2180544.

Comment 11 Chemal Pemail 2023-06-07 09:26:18 UTC
For 1,2,3 there is a four months old pull request at https://src.fedoraproject.org/rpms/emacs/pull-request/21

Comment 12 Benson Muite 2023-06-07 09:34:07 UTC
Thanks.

Comment 13 Red Hat Bugzilla 2023-10-06 04:25:07 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.