GNU bug report logs - #54996
Emacs hangs when editing Python code with debug-on-error set to t

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 54996 in the body.
You can then email your comments to 54996 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: Richard Stanton <rhstanton <at> berkeley.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs hangs when editing Python code with debug-on-error set to t
Date: Sun, 17 Apr 2022 13:16:26 -0700

Running Emacs 28.1 on MacOS 12.3.1, I’ve encountered a situation where Emacs hangs while editing Python code.

To see the problem, fire up Emacs 28.1 with init.el containing just one line:

———————
(setq debug-on-error t)
———————

Now open a Python file containing the following text:

———————
"""Text in triple double quotes"""
———————

Put the cursor right at the start of the file, on the first double quote, and press ‘, the single quote character. On my machine, Emacs now hangs and doesn’t respond to the keyboard. Without debug-on-error, this works just fine.

Best,

Richard Stanton

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stanton <rhstanton <at> berkeley.edu>
Cc: 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Sun, 17 Apr 2022 22:43:00 +0200

Richard Stanton <rhstanton <at> berkeley.edu> writes:

> Put the cursor right at the start of the file, on the first double
> quote, and press ‘, the single quote character. On my machine, Emacs
> now hangs and doesn’t respond to the keyboard. Without debug-on-error,
> this works just fine.

I can reproduce this, too (on Debian/bookworm).  `C-g' does work to
break it, but then it just hangs again almost immediately, so I guess
it's a problem in font-locking.

But it's bizarre that the debug-on-error setting should affect this.
I've skimmed through python.el looking for anything obvious (like a
`condition-case-unless-debug' but can't find anything).

The culprit must be in python-syntax-stringify -- if I just remove that,
the hang is gone.  But there's no odd error handling there that I can
see (unless it's hiding in syntax-ppss)...  anybody got any ideas?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rhstanton <at> berkeley.edu, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 08:46:51 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 17 Apr 2022 22:43:00 +0200
> Cc: 54996 <at> debbugs.gnu.org
> 
> Richard Stanton <rhstanton <at> berkeley.edu> writes:
> 
> > Put the cursor right at the start of the file, on the first double
> > quote, and press ‘, the single quote character. On my machine, Emacs
> > now hangs and doesn’t respond to the keyboard. Without debug-on-error,
> > this works just fine.
> 
> I can reproduce this, too (on Debian/bookworm).

And I cannot reproduce at all.  Does the recipe involve the Python
interpreter in any way?  If so, that might be the reason why it
doesn't reproduce here.

It is also not clear to me whether I should insert ‘ or ' (I tried
both).

> But it's bizarre that the debug-on-error setting should affect this.
> I've skimmed through python.el looking for anything obvious (like a
> `condition-case-unless-debug' but can't find anything).

Calling a debugger triggers a redisplay cycle, and maybe that explains
the problem.

> The culprit must be in python-syntax-stringify -- if I just remove that,
> the hang is gone.  But there's no odd error handling there that I can
> see (unless it's hiding in syntax-ppss)...  anybody got any ideas?

Catching a backtrace on the C level might explain what happens.  But
since I cannot reproduce the problem, I cannot show such a backtrace,
either.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rhstanton <at> berkeley.edu, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 11:45:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> And I cannot reproduce at all.  Does the recipe involve the Python
> interpreter in any way?  If so, that might be the reason why it
> doesn't reproduce here.

Nope, just font locking.

> It is also not clear to me whether I should insert ‘ or ' (I tried
> both).

It's '

>> But it's bizarre that the debug-on-error setting should affect this.
>> I've skimmed through python.el looking for anything obvious (like a
>> `condition-case-unless-debug' but can't find anything).
>
> Calling a debugger triggers a redisplay cycle, and maybe that explains
> the problem.

Hm, yes...

>> The culprit must be in python-syntax-stringify -- if I just remove that,
>> the hang is gone.  But there's no odd error handling there that I can
>> see (unless it's hiding in syntax-ppss)...  anybody got any ideas?
>
> Catching a backtrace on the C level might explain what happens.  But
> since I cannot reproduce the problem, I cannot show such a backtrace,
> either.

Do you have any suggestions about where to put a breakpoint?  I tried to
put a breakpoint on call_debugger, but nothing...

My test case is:

gdb --args ./src/emacs -geometry -0+0 --eval "(setq debug-on-error t)" -Q  /tmp/foo.py

with foo.py containing just that triple-quoted string.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rhstanton <at> berkeley.edu, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 13:02:52 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rhstanton <at> berkeley.edu,  54996 <at> debbugs.gnu.org
> Date: Mon, 18 Apr 2022 11:45:30 +0200
> 
> > Catching a backtrace on the C level might explain what happens.  But
> > since I cannot reproduce the problem, I cannot show such a backtrace,
> > either.
> 
> Do you have any suggestions about where to put a breakpoint?  I tried to
> put a breakpoint on call_debugger, but nothing...

In Fsignal, I guess.  But it is strange that call_debugger doesn't
trigger: do you see a *Backtrace* buffer popping up?

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rhstanton <at> berkeley.edu, Lars Ingebrigtsen <larsi <at> gnus.org>,
 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 12:56:00 +0200

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>
> Catching a backtrace on the C level might explain what happens.  But
> since I cannot reproduce the problem, I cannot show such a backtrace,
> either.

I can reproduce the problem on macOS.  I sampled Emacs during the hang
and I've attached the resulting call graph here.

[EmacsHang.txt (text/plain, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rhstanton <at> berkeley.edu, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 13:07:24 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> In Fsignal, I guess.  But it is strange that call_debugger doesn't
> trigger: do you see a *Backtrace* buffer popping up?

Nope, Emacs just hangs without popping up anything.

Breakpoing on Fsignal is called all the time, even without
debug-on-error, so it's too noisy to use.

#0  Fsignal (error_symbol=0x106b0, data=0x555556090af3) at eval.c:1649
#1  0x00005555555dcf9a in xsignal (data=<optimized out>, error_symbol=0x106b0)
    at /home/larsi/src/emacs/trunk/src/lisp.h:4514
#2  xsignal1 (error_symbol=error_symbol <at> entry=0x106b0, arg=arg <at> entry=0x2d1c30)
    at eval.c:1811
#3  0x00005555555dc6c8 in Fdefault_value (symbol=<optimized out>)
    at data.c:1952
#4  0x0000555555788478 in Fdefault_toplevel_value (symbol=0x2d1c30)
    at eval.c:709
#5  0x00005555557ced47 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#6  0x00005555557d154b in Fbyte_code
    (bytestr=<optimized out>, vector=0x555555d537e5, maxdepth=0x2a)
    at bytecode.c:329
#7  0x000055555578a161 in eval_sub (form=<optimized out>) at eval.c:2388
#8  0x00005555557bbb15 in readevalloop

And that's because defcustom uses errors as control flow:

(defun custom-initialize-default (symbol exp)
  "Initialize SYMBOL with EXP.
This will do nothing if symbol already has a default binding.
Otherwise, if symbol has a `saved-value' property, it will evaluate
the car of that and use it as the default binding for symbol.
Otherwise, EXP will be evaluated and used as the default binding for
symbol."
  (condition-case nil
      (default-toplevel-value symbol)   ;Test presence of default value.
    (void-variable
     ;; The var is not initialized yet.
     (set-default-toplevel-value
      symbol (eval (let ((sv (get symbol 'saved-value)))
                     (if sv (car sv) exp))
                   t)))))

Which has bitten me before when trying to do debugging...  could we
rewrite that somehow to avoid this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rhstanton <at> berkeley.edu, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 13:18:49 +0200

But here we go -- I instrumented Fsignal after loading everything.

gdb) xbacktrace 
"signal" (0xeabde738)
"error" (0xffff8378)
"apply" (0xeabde6e0)
"cl--assertion-failed" (0xeabde668)
"python-nav-end-of-statement" (0xeabde620)
"python-info-end-of-statement-p" (0xeabde5f0)
"python-info-end-of-block-p" (0xeabde598)
"python-nav--forward-sexp" (0xeabde518)
"python-nav-forward-sexp" (0xeabde4c0)
"python-nav-backward-sexp" (0xeabde468)
"python-info-docstring-p" (0xeabde408)
"python-font-lock-syntactic-face-function" (0xeabde3a8)
"font-lock-fontify-syntactically-region" (0xeabde320)
"font-lock-default-fontify-region" (0xeabde2b0)
"font-lock-fontify-region" (0xeabde240)
0x566c35a8 PVEC_COMPILED
"run-hook-wrapped" (0xeabde1c8)

I've now fixed this by avoiding cl-assert (which probably should never
be used inside a function called from font-lock).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rhstanton <at> berkeley.edu, Eli Zaretskii <eliz <at> gnu.org>, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 16:17:46 +0200

Am Mo., 18. Apr. 2022 um 13:19 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>
> But here we go -- I instrumented Fsignal after loading everything.
>
> gdb) xbacktrace
> "signal" (0xeabde738)
> "error" (0xffff8378)
> "apply" (0xeabde6e0)
> "cl--assertion-failed" (0xeabde668)
> "python-nav-end-of-statement" (0xeabde620)
> "python-info-end-of-statement-p" (0xeabde5f0)
> "python-info-end-of-block-p" (0xeabde598)
> "python-nav--forward-sexp" (0xeabde518)
> "python-nav-forward-sexp" (0xeabde4c0)
> "python-nav-backward-sexp" (0xeabde468)
> "python-info-docstring-p" (0xeabde408)
> "python-font-lock-syntactic-face-function" (0xeabde3a8)
> "font-lock-fontify-syntactically-region" (0xeabde320)
> "font-lock-default-fontify-region" (0xeabde2b0)
> "font-lock-fontify-region" (0xeabde240)
> 0x566c35a8 PVEC_COMPILED
> "run-hook-wrapped" (0xeabde1c8)
>
> I've now fixed this by avoiding cl-assert (which probably should never
> be used inside a function called from font-lock).
>

The assertion was added to protect against a subtle but nasty bug, see
commit 4fbd330fae54a9c45d4a717127aa86d75e9938d5. Please don't remove
the assertion without first ensuring that the bug won't reoccur.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: rhstanton <at> berkeley.edu, Eli Zaretskii <eliz <at> gnu.org>, 54996 <at> debbugs.gnu.org
Subject: Re: bug#54996: Emacs hangs when editing Python code with
 debug-on-error set to t
Date: Mon, 18 Apr 2022 16:23:16 +0200

Philipp Stephani <p.stephani2 <at> gmail.com> writes:

> The assertion was added to protect against a subtle but nasty bug, see
> commit 4fbd330fae54a9c45d4a717127aa86d75e9938d5. Please don't remove
> the assertion without first ensuring that the bug won't reoccur.

I changed it into a `when'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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