GNU bug report logs - #21657
25.0.50; Python mode goes into an infinite loop

Previous Next

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

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

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

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; Python mode goes into an infinite loop
Date: Fri, 09 Oct 2015 15:22:06 -0700

[Message part 1 (text/plain, inline)]

Hi. I'm running a very recent emacs:

 https://github.com/emacs-mirror/emacs/commit/7e83f50

Opening a trivial python source file (attached) with a trivial and
seemingly-unrelated .emacs.d/init.el (also attached) makes emacs spin
its wheels. Hitting C-g doesn't work to get control back. You actually
have to kill the process.

Thanks!

[emacsbreak.py (text/x-python, inline)]

"""
blah blah blah

"""

[init.el (application/emacs-lisp, attachment)]

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

From: Luke Powers <luke.powers <at> openx.com>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 21657 <at> debbugs.gnu.org
Subject: Re: bug#21657: 25.0.50; Python mode goes into an infinite loop
Date: Fri, 9 Oct 2015 16:16:32 -0700

[Message part 1 (text/plain, inline)]

There are a couple issues out there with similar reports (21646 21629
21628).

Revert to 818f06eaa72d8e4f9ba314c1c2855613bf89f396 if you want to work
around the issue.

On Fri, Oct 9, 2015 at 3:22 PM, Dima Kogan <dima <at> secretsauce.net> wrote:

> Hi. I'm running a very recent emacs:
>
>  https://github.com/emacs-mirror/emacs/commit/7e83f50
>
> Opening a trivial python source file (attached) with a trivial and
> seemingly-unrelated .emacs.d/init.el (also attached) makes emacs spin
> its wheels. Hitting C-g doesn't work to get control back. You actually
> have to kill the process.
>
> Thanks!
>
>

[Message part 2 (text/html, inline)]

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Luke Powers <luke.powers <at> openx.com>, Dima Kogan <dima <at> secretsauce.net>
Cc: 21657 <at> debbugs.gnu.org
Subject: Re: bug#21657: 25.0.50; Python mode goes into an infinite loop
Date: Mon, 12 Oct 2015 20:21:34 -0700

[Message part 1 (text/plain, inline)]

On 10/09/2015 04:16 PM, Luke Powers wrote:
> There are a couple issues out there with similar reports (21646 21629
> 21628).
> 
> Revert to 818f06eaa72d8e4f9ba314c1c2855613bf89f396 if you want to work
> around the issue.

I think I know what's going on. Stefan's change moved some of the
syntax-propertize stuff from Lisp into C. Now Emacs core has a variable
called syntax-propertize--done, known in C as syntax_propertize__done.
We make it buffer-local using Fmake_variable_buffer_local, but that
makes the variable buffer-local when it's _set_. Until it's set, the
variable retains its global value, which lives in the C variable
syntax_propertize__done. So if we syntax-propertize 1000 characters of
buffer A, then find-file in buffer B, we think we've syntax-propertized
up to position 1000 (the value of syntax_propertize__done) until we set
it to something else. In the case of Python, if we have a triple quote
in the first 1000 characters, we infloop.

[signature.asc (application/pgp-signature, attachment)]

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

From: immerrr again <immerrr <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 21657 <at> debbugs.gnu.org, Dima Kogan <dima <at> secretsauce.net>,
 Luke Powers <luke.powers <at> openx.com>
Subject: Re: bug#21657: 25.0.50; Python mode goes into an infinite loop
Date: Tue, 13 Oct 2015 07:58:07 +0300

There's a patch to fix this in #21671.

On Tue, Oct 13, 2015 at 6:21 AM, Daniel Colascione <dancol <at> dancol.org> wrote:
> I think I know what's going on. Stefan's change moved some of the
> syntax-propertize stuff from Lisp into C. Now Emacs core has a variable
> called syntax-propertize--done, known in C as syntax_propertize__done.
> We make it buffer-local using Fmake_variable_buffer_local, but that
> makes the variable buffer-local when it's _set_. Until it's set, the
> variable retains its global value, which lives in the C variable
> syntax_propertize__done. So if we syntax-propertize 1000 characters of
> buffer A, then find-file in buffer B, we think we've syntax-propertized
> up to position 1000 (the value of syntax_propertize__done) until we set
> it to something else. In the case of Python, if we have a triple quote
> in the first 1000 characters, we infloop.
>

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

From: Daniel Colascione <dancol <at> dancol.org>
To: immerrr again <immerrr <at> gmail.com>
Cc: 21657 <at> debbugs.gnu.org, Dima Kogan <dima <at> secretsauce.net>,
 Luke Powers <luke.powers <at> openx.com>
Subject: Re: bug#21657: 25.0.50; Python mode goes into an infinite loop
Date: Mon, 12 Oct 2015 22:05:42 -0700

[Message part 1 (text/plain, inline)]

Please don't top post.

On 10/12/2015 09:58 PM, immerrr again wrote:
> There's a patch to fix this in #21671.

I saw your message after I sent mine. How exactly is it supposed to
work? I can't reliably repro the condition that leads to the variable
being inherited across buffers (even with Torsten Bronger's testcase),
so I can't test it. It doesn't seem like adding a DEFSYM should make a
difference here though. Can you explain why your patch works?

[signature.asc (application/pgp-signature, attachment)]

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

From: immerrr again <immerrr <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 21657 <at> debbugs.gnu.org, Dima Kogan <dima <at> secretsauce.net>,
 Luke Powers <luke.powers <at> openx.com>
Subject: Re: bug#21657: 25.0.50; Python mode goes into an infinite loop
Date: Tue, 13 Oct 2015 08:42:07 +0300

On Tue, Oct 13, 2015 at 8:05 AM, Daniel Colascione <dancol <at> dancol.org> wrote:
> I saw your message after I sent mine. How exactly is it supposed to
> work? I can't reliably repro the condition that leads to the variable
> being inherited across buffers (even with Torsten Bronger's testcase),
> so I can't test it. It doesn't seem like adding a DEFSYM should make a
> difference here though. Can you explain why your patch works?
>

Apparently, I was testing a version that was older than [1] since it
was reproduced reliably. With it, the variable indeed seems properly
buffer-local. I think I misread commit metadata in git blame thinking
that the commit was from the last year, so I presumed that my Emacs
version already had it. I couldn't find any docs about obarray
initialization procedure (DEFSYM code-generation and alike), that was
the only place where Fmake_variable_buffer_local was invoked on
intern("foo") instead of a DEFSYM-initialized variable and I didn't
have much time to deduce from sources how these two approaches differ,
so I simply changed it to look like the others and ensured that it
worked after the change. Feel free to ignore that patch if it is
unnecessary.

1. https://github.com/emacs-mirror/emacs/commit/0360b7f2c4f0358106e229de4dfe91a67445a50c

Previous Next

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