GNU bug report logs - #24617
26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace

Previous Next

To reply to this bug, email your comments to 24617 AT debbugs.gnu.org.

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50;
 Handlers in `condition-case' should have programmatic access to the
 backtrace
Date: Tue, 04 Oct 2016 18:38:34 +0200

Currently a handler in a `condition-case' form doesn't have access to
the backtrace that was active when the signal was raised.  This makes
many useful things impossible, such as re-raising signals or returning
the backtrace to emacsclient.  I suggest either adding true exception
objects (storing the error symbol, data, and backtrace), or at least
providing a dynamic variable with the current backtrace.


In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-10-04 built on localhost
Repository revision: e2913dc880b9843bf69cf885270551bafeb46120
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --enable-checking
 --enable-check-lisp-object-type'

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

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win 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 term/tty-colors 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 obarray 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 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 97780 8564)
 (symbols 48 20400 0)
 (miscs 40 325 144)
 (strings 32 17956 4891)
 (string-bytes 1 589476)
 (vectors 16 13791)
 (vector-slots 8 454059 6998)
 (floats 8 183 34)
 (intervals 56 214 0)
 (buffers 976 12)
 (heap 1024 50411 1118))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

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

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
Date: Tue, 4 Oct 2016 15:41:33 -0400

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

This sounds like a great idea!

As an aside, note that these things are not impossible; just tricky.  You just need to register your own debugger, then in that debugger function re-throw the error after recording the backtrace.  You also need to increment num-nonmacro-input-events from the debugger.

Clément.

On 2016-10-04 12:38, Philipp Stephani wrote:
> 
> Currently a handler in a `condition-case' form doesn't have access to
> the backtrace that was active when the signal was raised.  This makes
> many useful things impossible, such as re-raising signals or returning
> the backtrace to emacsclient.  I suggest either adding true exception
> objects (storing the error symbol, data, and backtrace), or at least
> providing a dynamic variable with the current backtrace.
> 
> 
> In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
>  of 2016-10-04 built on localhost
> Repository revision: e2913dc880b9843bf69cf885270551bafeb46120
> Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
> System Description:	Ubuntu 14.04 LTS
> 
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
> 
> Configured using:
>  'configure --with-modules --enable-checking
>  --enable-check-lisp-object-type'
> 
> Configured features:
> XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
> 
> Important settings:
>   value of $LANG: en_US.UTF-8
>   locale-coding-system: utf-8-unix
> 
> Major mode: Lisp Interaction
> 
> Minor modes in effect:
>   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
> 
> Load-path shadows:
> None found.
> 
> Features:
> (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
> bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
> dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
> password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
> mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
> mail-utils time-date mule-util tooltip eldoc electric uniquify
> ediff-hook vc-hooks lisp-float-type mwheel term/x-win 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 term/tty-colors 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 obarray 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 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 97780 8564)
>  (symbols 48 20400 0)
>  (miscs 40 325 144)
>  (strings 32 17956 4891)
>  (string-bytes 1 589476)
>  (vectors 16 13791)
>  (vector-slots 8 454059 6998)
>  (floats 8 183 34)
>  (intervals 56 214 0)
>  (buffers 976 12)
>  (heap 1024 50411 1118))
> 

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

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

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24617: 26.0.50;
 Handlers in `condition-case' should have programmatic access to the
 backtrace
Date: Wed, 05 Oct 2016 08:16:46 +0200

On Tue, Oct 04 2016, Philipp Stephani wrote:

> Currently a handler in a `condition-case' form doesn't have access to
> the backtrace that was active when the signal was raised.  This makes
> many useful things impossible, such as re-raising signals or returning
> the backtrace to emacsclient.  I suggest either adding true exception
> objects (storing the error symbol, data, and backtrace), or at least
> providing a dynamic variable with the current backtrace.

First, you can copy the backtrace in a signal-hook-function and store it
in global variable.

Second, unconditionally copying the backtrace would be expensive and
would still not allow access to local variables in stack frames or the
value of dynamic variables at the point where the error was signalled
Just because Java or Python do that doesn't make it a great idea.

Third, the solution to this problem in Common Lisp is the HANDLER-CASE
macro which is similar to condition-case but the error handlers are
executed without unwinding the stack.  That doesn't require any copying
and gives full access to the stack. (Again, can be emulated with a
signal-hook-function.)  Of course, that approach can't be used to handle
things like stack overflow or only if done very carefully.

Helmut

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>, 
 24617 <at> debbugs.gnu.org
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
Date: Wed, 28 Dec 2016 19:33:42 +0000

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

Clément Pit--Claudel <clement.pit <at> gmail.com> schrieb am Di., 4. Okt. 2016
um 21:42 Uhr:

> This sounds like a great idea!
>
> As an aside, note that these things are not impossible; just tricky.  You
> just need to register your own debugger, then in that debugger function
> re-throw the error after recording the backtrace.  You also need to
> increment num-nonmacro-input-events from the debugger.
>

Yeah, that sounds like a quite hackish way - it means the debugger wasn't
really intended to be used that way.

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

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>, 24617 <at> debbugs.gnu.org
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
Date: Wed, 28 Dec 2016 20:08:12 +0000

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

Helmut Eller <eller.helmut <at> gmail.com> schrieb am Mi., 5. Okt. 2016 um
08:18 Uhr:

> On Tue, Oct 04 2016, Philipp Stephani wrote:
>
> > Currently a handler in a `condition-case' form doesn't have access to
> > the backtrace that was active when the signal was raised.  This makes
> > many useful things impossible, such as re-raising signals or returning
> > the backtrace to emacsclient.  I suggest either adding true exception
> > objects (storing the error symbol, data, and backtrace), or at least
> > providing a dynamic variable with the current backtrace.
>
> First, you can copy the backtrace in a signal-hook-function and store it
> in global variable.
>

Yes, that sounds like a good workaround, with the downside that other
libraries might override signal-hook-function and disable that
functionality.
Do you know why ERT uses a custom debugger instead of signal-hook-function?


>
> Second, unconditionally copying the backtrace would be expensive


Are you sure about that? In languages that are typically far more
performance-sensitive (e.g. Java), the backtrace is also copied
unconditionally.


> and
> would still not allow access to local variables in stack frames or the
> value of dynamic variables at the point where the error was signalled
> Just because Java or Python do that doesn't make it a great idea.
>

True, but having the function names and argument values is better than
nothing when debugging the cause of a signal.


>
> Third, the solution to this problem in Common Lisp is the HANDLER-CASE
> macro which is similar to condition-case but the error handlers are
> executed without unwinding the stack.  That doesn't require any copying
> and gives full access to the stack.


That sounds like an interesting approach that could be made to solve some
common use cases (e.g. test runners or rethrowing signals).

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

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

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24617 <at> debbugs.gnu.org
Subject: Re: bug#24617: 26.0.50;
 Handlers in `condition-case' should have programmatic access to the
 backtrace
Date: Thu, 29 Dec 2016 10:01:48 +0100

On Wed, Dec 28 2016, Philipp Stephani wrote:

> Yes, that sounds like a good workaround, with the downside that other
> libraries might override signal-hook-function and disable that
> functionality.
> Do you know why ERT uses a custom debugger instead of
> signal-hook-function?

No. (I didn't write ERT.)  Maybe it's difficult to determine
whether/where a condition will be handled from a signal-hook-function.

>     Second, unconditionally copying the backtrace would be expensive
>
>
> Are you sure about that?

No, but I would be surprised if it were cheap.

Helmut

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

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
Date: Thu, 29 Dec 2016 15:02:53 +0100

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

On 12/29/2016 10:01 AM, Helmut Eller wrote:
>>     Second, unconditionally copying the backtrace would be expensive
>>
>> Are you sure about that?
>
> No, but I would be surprised if it were cheap.

Collecting the textual backtrace (by calling 'backtrace') can take arbitrarily long, because it includes arguments, which can be large strings. I've run into this (99% of the time was spent on collecting backtraces).

Collecting a full backtrace with backtrace-frame (as objects) is quadratic, but I don't know if that matters.  The master branch has mapbacktrace, which solves the quadratic part.

Clément.

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

Previous Next

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