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

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

[Philipp Stephani]

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.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 3816 bytes --]

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))
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Helmut Eller]

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

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

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Clément Pit--Claudel <clement.pit@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.

[-- Attachment #2: Type: text/html, Size: 854 bytes --]

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

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

Helmut Eller <eller.helmut@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).

[-- Attachment #2: Type: text/html, Size: 3030 bytes --]

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

[Helmut Eller]

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

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]