GNU bug report logs - #31671
26.1; edebug-defun doesn't step if functions run in a separate thread

Previous Next

Package: emacs;

Reported by: Raimon Grau <raimon <at> konghq.com>

Date: Thu, 31 May 2018 17:45:01 UTC

Severity: normal

Tags: confirmed

Found in version 26.1

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: raimon <at> konghq.com, 31671 <at> debbugs.gnu.org
Subject: bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread
Date: Tue, 05 Jun 2018 17:47:52 +0300
> Date: Mon, 4 Jun 2018 10:23:58 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 31671 <at> debbugs.gnu.org
> 
> > The problem here is that Edebug enters recursive-editing (on the
> > non-main thread which runs the function 'foo'), then waits for the
> > user to press a key.  While it waits, it releases the global lock, and
> > the main thread starts running.  So when you press a key, you are on a
> > different thread, and 'throw' doesn't have a matching 'catch' (because
> > that 'catch' is stored with the handlers of the thread which runs
> > 'foo'.
> > 
> > Not yet sure how to deal with this.  Thoughts and ideas are welcome.
> 
> Not really following this thread, and 100% unknowledgable
> about Emacs threading.  But somewhat curious: Does the same
> problem exist for plain `debug' as for `edebug'?

Yes.  Modify the recipe like this, and you have the same problem with
'debug':

  emacs -Q
  Type:

    (defun foo ()
      (message "Hi"))

  Eval the function to define it.
  M-x debug-on-entry RET foo RET
  M-: (make-thread 'foo) RET

  Type 'd' in the backtrace that Emacs presents.




This bug report was last modified 7 years and 59 days ago.

Previous Next


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