Bug 2187041

Summary: jit-lock-function enters busy loop when open """ near top of some python programs
Product: [Fedora] Fedora Reporter: Nick Urbanik <nicku>
Component: emacsAssignee: Daiki Ueno <dueno>
Status: CLOSED COMPLETED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 37CC: benson_muite, dan.cermak, dueno, gordon.messmer, jkeating, mlampe0, msekleta, phracek, robinlee.sysu, swt
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-05 13:43:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
This program can reproduce the bug reliably.
none
upstream fix none

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