From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luke Powers Newsgroups: gmane.emacs.bugs Subject: bug#21629: 25.0.50; python.el freezes up around docstrings. Date: Thu, 8 Oct 2015 11:22:20 -0700 Message-ID: References: <83fv1oxd2v.fsf@gnu.org> <56167D6A.5070507@easy-emacs.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc80009ab5e405219bf1ac X-Trace: ger.gmane.org 1444330820 24337 80.91.229.3 (8 Oct 2015 19:00:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Oct 2015 19:00:20 +0000 (UTC) Cc: 21629@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 08 21:00:08 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from eggs.gnu.org ([208.118.235.92]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZkGQA-0000wU-Jk for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 21:00:06 +0200 Original-Received: from lists.gnu.org ([208.118.235.17]:36268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkGQ9-00057S-K9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 15:00:05 -0400 Original-Received: from localhost ([::1]:36602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkGQ9-00023w-Dw for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 Oct 2015 15:00:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkGMI-0001tj-Uz for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 14:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkGME-0003oQ-QV for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 14:56:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkGME-0003oJ-KQ for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 14:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZkGME-0000Lz-9D for bug-gnu-emacs@gnu.org; Thu, 08 Oct 2015 14:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Luke Powers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Oct 2015 18:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21629 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21629-submit@debbugs.gnu.org id=B21629.14443305291310 (code B ref 21629); Thu, 08 Oct 2015 18:56:02 +0000 Original-Received: (at 21629) by debbugs.gnu.org; 8 Oct 2015 18:55:29 +0000 Original-Received: from localhost ([127.0.0.1]:33009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZkGLg-0000L4-NN for submit@debbugs.gnu.org; Thu, 08 Oct 2015 14:55:29 -0400 Original-Received: from mail-ig0-f174.google.com ([209.85.213.174]:34659) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZkFpd-0007zX-CF for 21629@debbugs.gnu.org; Thu, 08 Oct 2015 14:22:21 -0400 Original-Received: by igcpb10 with SMTP id pb10so21225244igc.1 for <21629@debbugs.gnu.org>; Thu, 08 Oct 2015 11:22:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=EnIinkTMrm7m4l2F8trazo//wGbk94Pd5to9OSVH/V8=; b=SN3cLoN83fId88PCkjQWZfvKjYl2FZ6Mh4lcXH5OJH8IROTTysW2ZjsBQMUsL6we0x JAykkrqVpMDPCf+sDJ9WZVw62GxWVi7w2qC9U4IiSInbNlmvsgpsA2PW0ylR+AVM8WM4 tNxc1OAogYIC9w1PWZl2NokIUWMUPC3Vuj6gAy4PPpGaF9HitRSSUASHRT1Jl4N8CNcq KFL3c/ofYyfa2OYzNK06w39ysEUyOj2PtLi70BHMMLyCr3g1brCmRxRJZiNUx+IuP/IS 7SQUYkocp4kGIP0xY9W5xaW3Ql6PtNiQiUi1XfxJulffuRb3mWdtV8GYpBkyYM0lVw0D GuMw== X-Gm-Message-State: ALoCoQmZy8yTFcvZUdpbwriopycopp4E1bkgm+EyB2Nejb28lCjVoSBw+gpgGpIV1V0uwug1DlML X-Received: by 10.50.59.179 with SMTP id a19mr3648514igr.67.1444328540640; Thu, 08 Oct 2015 11:22:20 -0700 (PDT) Original-Received: by 10.107.152.10 with HTTP; Thu, 8 Oct 2015 11:22:20 -0700 (PDT) In-Reply-To: <56167D6A.5070507@easy-emacs.de> X-Mailman-Approved-At: Thu, 08 Oct 2015 14:55:27 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x Xref: news.gmane.org gmane.emacs.bugs:107456 Archived-At: --047d7bdc80009ab5e405219bf1ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable fwiw, I went through the tree with bisect and found 3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea to be the first commit where the issue pops up. On Thu, Oct 8, 2015 at 7:27 AM, Andreas R=C3=B6hler < andreas.roehler@easy-emacs.de> wrote: > > Am 06.10.2015 um 16:54 schrieb Eli Zaretskii: > >> From: Jacob MacDonald >>> Date: Tue, 06 Oct 2015 04:48:50 +0000 >>> >>> Begin from a fresh 'emacs -Q'. Create a Python file. Insert a long >>> docstring which contains a header line and then a long body which >>> includes a few line breaks and spaces in it. The docstring should look >>> something like this: >>> >>> """test header >>> >>> lorem ipsum... more text more text more text >>> x10 lines >>> ... >>> ... >>> """ >>> >>> Save the file and close emacs. Start a fresh 'emacs -Q'. Open dired in >>> the directory which contains the Python file you created. Navigate to >>> the file and try to open in from dired. Emacs will freeze indefinitely >>> and eat all the system resources it can. You can break the cycle by >>> pressing C-q many times, but the freeze happens again on every single >>> redisplay. If you wait awhile before cancelling the redisplay, you may >>> see that fontification has frozen somewhere in the middle of the >>> docstring. >>> >> It infloops in python-nav-end-of-statement. The loop there ends up >> one position before EOB, then jumps back to string-start, and so on >> and so forth, ad nauseam. >> >> I have no idea what causes this, but I hope Python-mode experts and >> perhaps Stefan (due to syntax stuff) will be able to figure this out. >> >> >> >> >> > With a while-loop reading complex conditions IMO there is always an > abstract danger. > > python-mode.el uses a heuristic exit: > > `py-max-specpdl-size' - default is `max-specpdl-size' > > > > --047d7bdc80009ab5e405219bf1ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
fwiw, I went through the tree with bisect and found 3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea to be the fir= st commit where the issue pops up.

=
On Thu, Oct 8, 2015 at 7:27 AM, Andreas R=C3=B6h= ler <andreas.roehler@easy-emacs.de> wrote:

Am 06.10.2015 um 16:54 schrieb Eli Zaretskii:
From: Jacob MacDonald <jaccarmac@gmail.com>
Date: Tue, 06 Oct 2015 04:48:50 +0000

Begin from a fresh 'emacs -Q'. Create a Python file. Insert a long<= br> docstring which contains a header line and then a long body which
includes a few line breaks and spaces in it. The docstring should look
something like this:

"""test header

lorem ipsum... more text more text more text
x10 lines
...
...
"""

Save the file and close emacs. Start a fresh 'emacs -Q'. Open dired= in
the directory which contains the Python file you created. Navigate to
the file and try to open in from dired. Emacs will freeze indefinitely
and eat all the system resources it can. You can break the cycle by
pressing C-q many times, but the freeze happens again on every single
redisplay. If you wait awhile before cancelling the redisplay, you may
see that fontification has frozen somewhere in the middle of the docstring.=
It infloops in python-nav-end-of-statement.=C2=A0 The loop there ends up one position before EOB, then jumps back to string-start, and so on
and so forth, ad nauseam.

I have no idea what causes this, but I hope Python-mode experts and
perhaps Stefan (due to syntax stuff) will be able to figure this out.





With a while-loop reading complex conditions IMO there is always an abstrac= t danger.

python-mode.el uses a heuristic exit:

`py-max-specpdl-size' - default is `max-specpdl-size'




--047d7bdc80009ab5e405219bf1ac--