GNU bug report logs - #21629
25.0.50; python.el freezes up around docstrings.

Previous Next

Package: emacs;

Reported by: Jacob MacDonald <jaccarmac <at> gmail.com>

Date: Tue, 6 Oct 2015 05:44:02 UTC

Severity: normal

Tags: confirmed, fixed, patch

Merged with 21628, 21646, 21657, 21671, 24839, 24856, 24905, 26041

Found in versions 25.0.50, 25.1, 25.1.50, 26.0.50

Fixed in version 25.2

Done: Daniel Colascione <dancol <at> dancol.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21629 in the body.
You can then email your comments to 21629 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#21629; Package emacs. (Tue, 06 Oct 2015 05:44:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jacob MacDonald <jaccarmac <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 06 Oct 2015 05:44:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jacob MacDonald <jaccarmac <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; python.el freezes up around docstrings.
Date: Tue, 06 Oct 2015 04:48:50 +0000
[Message part 1 (text/plain, inline)]
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.


In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.7)
 of 2015-10-05
Repository revision: 25b4572073179c8d6dc980ce2df3db4d96cd692f
Windowing system distributor 'The X.Org Foundation', version 11.0.11702000
System Description: Ubuntu Wily Werewolf (development branch)

Configured using:
 'configure --prefix=/home/jaccarmac/local/emacs'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY LIBXML2 FREETYPE XFT
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Python

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Error during redisplay: (jit-lock-function 201) signaled (quit)
Error during redisplay: (jit-lock-function 301) signaled (quit)
Error during redisplay: (jit-lock-function 1) signaled (quit)
Error during redisplay: (jit-lock-function 101) signaled (quit)
Error during redisplay: (jit-lock-function 201) signaled (quit)
Error during redisplay: (jit-lock-function 301) signaled (quit)
QuitError during redisplay: (jit-lock-function 1) signaled (quit)
Error during redisplay: (jit-lock-function 101) signaled (quit)
Error during redisplay: (jit-lock-function 201) signaled (quit)
Error during redisplay: (jit-lock-function 301) signaled (quit)
Quit [2 times]

Load-path shadows:
None found.

(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils python tramp-sh tramp
tramp-compat auth-source cl-seq eieio byte-opt bytecomp byte-compile
cl-extra cconv eieio-core cl-macs gv gnus-util mm-util help-fns
help-mode easymenu mail-prsvr password-cache tramp-loaddefs trampver
shell pcomplete format-spec advice json comint ring cl-loaddefs pcase
cl-lib ansi-color dired time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 103996 4041)
 (symbols 48 21982 0)
 (miscs 40 288 118)
 (strings 32 22819 5081)
 (string-bytes 1 758868)
 (vectors 16 15247)
 (vector-slots 8 457945 4629)
 (floats 8 185 420)
 (intervals 56 237 0)
 (buffers 976 14)
 (heap 1024 22367 1150))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21629; Package emacs. (Tue, 06 Oct 2015 14:55:02 GMT) Full text and rfc822 format available.

Message #8 received at 21629 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jacob MacDonald <jaccarmac <at> gmail.com>
Cc: 21629 <at> debbugs.gnu.org
Subject: Re: bug#21629: 25.0.50; python.el freezes up around docstrings.
Date: Tue, 06 Oct 2015 17:54:00 +0300
> From: Jacob MacDonald <jaccarmac <at> gmail.com>
> 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.





Added indication that bug 21629 blocks19759 Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 06 Oct 2015 16:40:04 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21629; Package emacs. (Thu, 08 Oct 2015 14:29:02 GMT) Full text and rfc822 format available.

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#21629: 25.0.50; python.el freezes up around docstrings.
Date: Thu, 08 Oct 2015 16:27:54 +0200
Am 06.10.2015 um 16:54 schrieb Eli Zaretskii:
>> From: Jacob MacDonald <jaccarmac <at> gmail.com>
>> 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'




Merged 21629 21646. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 08 Oct 2015 16:32:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#21629; Package emacs. (Thu, 08 Oct 2015 18:56:02 GMT) Full text and rfc822 format available.

Message #18 received at 21629 <at> debbugs.gnu.org (full text, mbox):

From: Luke Powers <luke.powers <at> openx.com>
Cc: 21629 <at> debbugs.gnu.org
Subject: Re: bug#21629: 25.0.50; python.el freezes up around docstrings.
Date: Thu, 8 Oct 2015 11:22:20 -0700
[Message part 1 (text/plain, inline)]
fwiw, I went through the tree with bisect and found
3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea
<https://github.com/emacs-mirror/emacs/commit/3928ef2dd5b8febf3b1d9c1bfb22af3698d16bea>
to be the first commit where the issue pops up.

On Thu, Oct 8, 2015 at 7:27 AM, Andreas Röhler <
andreas.roehler <at> easy-emacs.de> wrote:

>
> Am 06.10.2015 um 16:54 schrieb Eli Zaretskii:
>
>> From: Jacob MacDonald <jaccarmac <at> gmail.com>
>>> 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'
>
>
>
>
[Message part 2 (text/html, inline)]

Merged 21628 21629 21646 21657. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Fri, 09 Oct 2015 22:28:01 GMT) Full text and rfc822 format available.

Merged 21628 21629 21646 21657 21671. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 12 Oct 2015 20:39:01 GMT) Full text and rfc822 format available.

Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 23 Feb 2016 09:07:03 GMT) Full text and rfc822 format available.

bug marked as fixed in version 25.1, send any further explanations to 21628 <at> debbugs.gnu.org and Torsten Bronger <bronger <at> physik.rwth-aachen.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 23 Feb 2016 09:07:03 GMT) Full text and rfc822 format available.

bug No longer marked as fixed in versions 25.1 and reopened. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 23 Feb 2016 10:05:02 GMT) Full text and rfc822 format available.

Forcibly Merged 21628 21629 21646 21657 21671 24839 24856 24905. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Wed, 01 Mar 2017 01:06:02 GMT) Full text and rfc822 format available.

Merged 21628 21629 21646 21657 21671 24839 24856 24905 26041. Request was from npostavs <at> users.sourceforge.net to control <at> debbugs.gnu.org. (Thu, 09 Mar 2017 23:14:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 07 Apr 2017 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 71 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.