emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58780: closed (python.el infinite loop in info-current-defun)


From: GNU bug Tracking System
Subject: bug#58780: closed (python.el infinite loop in info-current-defun)
Date: Thu, 09 Mar 2023 10:17:02 +0000

Your message dated Thu, 09 Mar 2023 12:16:37 +0200
with message-id <837cvq2pru.fsf@gnu.org>
and subject line Re: bug#58780: python.el infinite loop in info-current-defun
has caused the debbugs.gnu.org bug report #58780,
regarding python.el infinite loop in info-current-defun
to be marked as done.

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


-- 
58780: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58780
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: python.el infinite loop in info-current-defun Date: Tue, 25 Oct 2022 15:06:36 -0400
I noticed python.el hangs hard on some of my files when `python-info-current-defun` is set up for use with which-function, and I open (but haven’t yet closed) a triple string: “”".  I tracked this down to a bug in `python-nav-end-of-statement` when an unclosed string is included in a file:

==========
def try():
    """Do the Foo

def a():
    """Do A's stuff"""
    a = True

===========

(Note: the final newline is important).  (python-info-current-defun) hangs on the unclosed docsig string of try().  

The reason why can be demonstrated by placing the cursor before a = True on the final line and (python-nav-end-of-statement).  Point moves to the end of the previous line!   Since `python-nav-end-of-defun` calls end-of-statement repeatedly looking for (eobp), this results in an infinite loop.  The problem is this call in end-of-statement:

  (re-search-forward (rx (syntax string-delimiter)) nil t)

Search starts at the single apostrophe in Do A’s stuff (the beginning of the apparent-but-incorrect string ppss has found), then searches forward to the triple quote at the end of the (prior) line.  

To reproduce this you need:

- an unclosed triple string above
- a triple string with another type of quote mark enclosed
- something after the final “”” (to prevent eobp). 

These are surprisingly common conditions to encounter given python docstring format.  A fix might be to insist that the `python-nav-end-of-statement` occurs at least at the end of the current line, or perhaps to improve the regex search for the end of string to match the opening string delimiter (although this could also be fooled I think).

This is Emacs 28, though aside from some additional commentary about such issues, end-of-statement hasn’t changed in the latest. 

As an aside, having stepped through this code, it seems python’s structural navigation and inspection are _very_ heavy, commonly traversing entire files one statement at a time to find the local function name, for example.  Due to their complexity, they are also susceptible to these types of infinite loops when syntax is in a temporarily broken state.  Good arguments for the inclusion of tree-sitter!


--- End Message ---
--- Begin Message --- Subject: Re: bug#58780: python.el infinite loop in info-current-defun Date: Thu, 09 Mar 2023 12:16:37 +0200
> Date: Sun, 05 Mar 2023 17:19:43 +0900
> From: kobarity <kobarity@gmail.com>
> 
> The attached
> 0001-Fix-searching-for-end-of-string-in-python-nav-end-of.patch is my
> proposal to fix this issue with some ERTs.  `forward-sexp' (in fact
> `python-nav--lisp-forward-sexp') is added to search for the end of the
> string if the string begins with single single/double-quote (' or ").
> 
> I think this 0001 patch also fixes Bug#56271.  At least, it passes the
> ERT python-nav-end-of-block-2 which is introduced in Bug#56271, even
> the workaround introduced in Bug#56271 is reverted.  The attached
> 0002-Revert-workaround-introduced-in-Bug-56271.patch is a patch to
> revert the workaround.  If the 0001 patch is accepted, the 0002 patch
> can also be applied.  But if we want to be safer, we can leave the
> workaround as it is by not applying the 0002 patch.
> 
> I look forward to your comments.

There were no more comments, so I've now installed both patches on the
emacs-29 branch, and I'm boldly closing this bug.

Thanks.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]