GNU logs - #24617, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Oct 2016 16:39:02 +0000
Resent-Message-ID: <handler.24617.B.147559913412460 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 24617 <at> debbugs.gnu.org
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Tue, 04 Oct 2016 18:38:34 +0200
Message-ID: <wvr4y4249iid.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


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

--=20
Google Germany GmbH
Erika-Mann-Stra=C3=9Fe 33
80636 M=C3=BCnchen

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Gesch=C3=A4ftsf=C3=BChrer: 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=C3=
=B6schen
Sie die E-Mail und alle Anh=C3=A4nge.  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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Philipp Stephani <p.stephani2@HIDDEN>
Subject: bug#24617: Acknowledgement (26.0.50; Handlers in `condition-case'
 should have programmatic access to the backtrace)
Message-ID: <handler.24617.B.147559913412460.ack <at> debbugs.gnu.org>
References: <wvr4y4249iid.fsf@HIDDEN>
X-Gnu-PR-Message: ack 24617
X-Gnu-PR-Package: emacs
Reply-To: 24617 <at> debbugs.gnu.org
Date: Tue, 04 Oct 2016 16:39:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 24617 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
24617: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D24617
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Oct 2016 19:42:02 +0000
Resent-Message-ID: <handler.24617.B.147561011329997 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 24617 <at> debbugs.gnu.org
References: <wvr4y4249iid.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@HIDDEN>
Message-ID: <70fe21b3-e7d9-111c-394c-f8554ac90453@HIDDEN>
Date: Tue, 4 Oct 2016 15:41:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <wvr4y4249iid.fsf@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="UkW86Bsmdj1M4OWpCFFlSjfgAEcjfuTKw"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--UkW86Bsmdj1M4OWpCFFlSjfgAEcjfuTKw
Content-Type: multipart/mixed; boundary="FPfoLabaBjwPKADxAmQPi1u3ClFGkhr87";
 protected-headers="v1"
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Message-ID: <70fe21b3-e7d9-111c-394c-f8554ac90453@HIDDEN>
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
References: <wvr4y4249iid.fsf@HIDDEN>
In-Reply-To: <wvr4y4249iid.fsf@HIDDEN>

--FPfoLabaBjwPKADxAmQPi1u3ClFGkhr87
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 incre=
ment num-nonmacro-input-events from the debugger.

Cl=C3=A9ment.

On 2016-10-04 12:38, Philipp Stephani wrote:
>=20
> 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.
>=20
>=20
> 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.11501=
000
> System Description:	Ubuntu 14.04 LTS
>=20
> Recent messages:
> For information about GNU Emacs and the GNU system, type C-h C-a.
>=20
> Configured using:
>  'configure --with-modules --enable-checking
>  --enable-check-lisp-object-type'
>=20
> Configured features:
> XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
>=20
> Important settings:
>   value of $LANG: en_US.UTF-8
>   locale-coding-system: utf-8-unix
>=20
> Major mode: Lisp Interaction
>=20
> 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
>=20
> Load-path shadows:
> None found.
>=20
> 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-loaddef=
s
> 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 georgia=
n
> 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 nadvic=
e
> 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)
>=20
> 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))
>=20


--FPfoLabaBjwPKADxAmQPi1u3ClFGkhr87--

--UkW86Bsmdj1M4OWpCFFlSjfgAEcjfuTKw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX9AXtAAoJEPqg+cTm90wjNIUP/jgcgU12HGjT+Lbfe1Qh8C4C
03s2wPO6krm/KnvD8ZdNemjyGrXx89O2/7gh8fGM4DcOAwhasLZCRm7D7u1/Oh3N
3nlSbzH5avxpcF3FZkzgv8Osfoic2AoiunXn0Q41uJyGUCdgHSND0TY3CTMnTjeD
ZkFP4iTzEU+aUlQmQzs5jZdWHi9+djmBJkGcp6RdrBDciNkvoLd2hKIbSKtMZIue
B1u+oL+nme8LzdaiwtdGl/6WZ+PtJScVCNyQ2tn0/c8ICziop8Txc/1LW9Bm7FZJ
6OHmcz/Sm8Br1jk0inx0Oo5FgiErHxjX/tuqtHaUGPPBizxx4s3NFa5Z3jt2VPJn
1DpmO9FmyjLVvnRS9TJbaXpgyQjdzZ3MWqzvIMQ+ikUdqtcHrvGPylBCbbL2DUuV
3zrIq02bV29Qcglp9QszR+LDpx8naKTdi3gH6xsky7XOyNDKR2ofF5TMfHqZQ4ym
QdpcPF4Pd6PyZYC4I67DpteuAtVPd1IgWqXAUsQrXtbyg0rkYjQv+ZqqQ5SFBysd
EudAd2OSkb85FrRnHSnDOp4YfOJDiVordMmXOPJz8gAJMFvb1IVkeSQhDHU4GIBO
XR8JnUdJ9nnu98mEmFY8rGPXLWK9vTTxq4gno3jcvc9ypZCJZZVFPXfgvf8Dv7Ww
7yIHKh5BiFwJdYyLKvA/
=3zxg
-----END PGP SIGNATURE-----

--UkW86Bsmdj1M4OWpCFFlSjfgAEcjfuTKw--

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
In-Reply-To: <wvr4y4249iid.fsf@HIDDEN>
Resent-From: Helmut Eller <eller.helmut@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Oct 2016 06:18:02 +0000
Resent-Message-ID: <handler.24617.B.147564825413354 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 24617 <at> debbugs.gnu.org
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Wed, 05 Oct 2016 08:16:46 +0200
Lines: 26
Message-ID: <m28tu3z5f5.fsf@HIDDEN>
References: <wvr4y4249iid.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
Cancel-Lock: sha1:jEZ7Zh/RJ63pVl3FhadKxu5DB90=
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 28 Dec 2016 19:34:01 +0000
Resent-Message-ID: <handler.24617.B24617.14829536406085 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 24617
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@HIDDEN>,  24617 <at> debbugs.gnu.org
Received: via spool by 24617-submit <at> debbugs.gnu.org id=B24617.14829536406085
          (code B ref 24617); Wed, 28 Dec 2016 19:34:01 +0000
Received: (at 24617) by debbugs.gnu.org; 28 Dec 2016 19:34:00 +0000
Received: from localhost ([127.0.0.1]:58292 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cMJz6-0001a4-IA
	for submit <at> debbugs.gnu.org; Wed, 28 Dec 2016 14:34:00 -0500
Received: from mail-wm0-f46.google.com ([74.125.82.46]:35802)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1cMJz4-0001Zr-7o
 for 24617 <at> debbugs.gnu.org; Wed, 28 Dec 2016 14:33:58 -0500
Received: by mail-wm0-f46.google.com with SMTP id a197so288740184wmd.0
 for <24617 <at> debbugs.gnu.org>; Wed, 28 Dec 2016 11:33:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=8ZpGtWygm9Wr8M3ZSznkViQeV2qD7cMUtw8PHCzO2WQ=;
 b=B57BfU5FJ+EjaIjuO0j4W87efl6A0rHrx1E9q9NSjqY6b0bJV5QJwfUASsA/yOIlIS
 H0oH0ceWKfiYj5VbLOGHsh6Ap2R6HXQ0SBLzFsyFB0juuz+JPkguKMJ9MHV9s9attVLr
 Oca0js1Rmdq7K0dnjmbhbgIdvIcOBMIiKNYLfKDh7GRHYKa3aq9IUm8Hx9+oHG2kyYZg
 PZA6KOteaB6NGrAIGi59acBLIzlorApzpNxgAGCD+mtjnFsOwv0NkaxhduebmeFV/M+0
 TVJeqS83QyyIJEO/nCBtkGVEIHcSBvRDTycBeuBFKHxL01++8JSCEvfJ41qkTLXdczLp
 gaUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=8ZpGtWygm9Wr8M3ZSznkViQeV2qD7cMUtw8PHCzO2WQ=;
 b=sQsvNefJNxyHIZNR0imNGTE7x4u7rWepEV53s7b9wqtX0DQqC94OSy7B0VQqJtTA1X
 Jum9FvxuUWDoZ/rGJP65nTAKX8IcC6AO0iH9ySB+KOMm2Ntb0W0wmtJ1OJwtZFpK+kLe
 u524HIDiX6P8AM4uu8wKyiADfj7tv8D81WbluiI5XhDm7K1jTh6A0Gnj70YgKpIZraNr
 RxBZJQ7QeXEvCKcKbkLT3IX8IXkyKhJ9HqrHPryva+SL2vhpJzpNIPa/zfhtbmzLPQCK
 D9336D8WHeOPSctqYG0ED7lEG7iqWx6269IqYRIUQ/DvREHqo5xgOh0P4Bj682ckMvRN
 QHfA==
X-Gm-Message-State: AIkVDXJr5dfnVGt6QLF6XrTU83ntKxgFotsRvQyRGazhnauxGTIqng5GyTc8vzxjdjZGp5E1DB7aQjLlA3aBiQ==
X-Received: by 10.28.140.148 with SMTP id o142mr26800640wmd.48.1482953632321; 
 Wed, 28 Dec 2016 11:33:52 -0800 (PST)
MIME-Version: 1.0
References: <wvr4y4249iid.fsf@HIDDEN>
 <70fe21b3-e7d9-111c-394c-f8554ac90453@HIDDEN>
In-Reply-To: <70fe21b3-e7d9-111c-394c-f8554ac90453@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Wed, 28 Dec 2016 19:33:42 +0000
Message-ID: <CAArVCkQXsDdd0W1KP53_fBd9U2gfnvcUWasxfjuYgcjvUjBDQA@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1146eeaa791fb30544bd0c0d
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

--001a1146eeaa791fb30544bd0c0d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Cl=C3=A9ment Pit--Claudel <clement.pit@HIDDEN> schrieb am Di., 4. Okt. 2=
016
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.

--001a1146eeaa791fb30544bd0c0d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Cl=C3=
=A9ment Pit--Claudel &lt;<a href=3D"mailto:clement.pit@HIDDEN">clement.p=
it@HIDDEN</a>&gt; schrieb am Di., 4. Okt. 2016 um 21:42=C2=A0Uhr:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">This sounds like a great idea!<br class=
=3D"gmail_msg">
<br class=3D"gmail_msg">
As an aside, note that these things are not impossible; just tricky.=C2=A0 =
You just need to register your own debugger, then in that debugger function=
 re-throw the error after recording the backtrace.=C2=A0 You also need to i=
ncrement num-nonmacro-input-events from the debugger.<br class=3D"gmail_msg=
">
</blockquote><div><br></div><div>Yeah, that sounds like a quite hackish way=
 - it means the debugger wasn&#39;t really intended to be used that way.=C2=
=A0</div></div></div>

--001a1146eeaa791fb30544bd0c0d--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: Philipp Stephani <p.stephani2@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 28 Dec 2016 20:09:01 +0000
Resent-Message-ID: <handler.24617.B24617.14829557119217 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 24617
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Helmut Eller <eller.helmut@HIDDEN>, 24617 <at> debbugs.gnu.org
Received: via spool by 24617-submit <at> debbugs.gnu.org id=B24617.14829557119217
          (code B ref 24617); Wed, 28 Dec 2016 20:09:01 +0000
Received: (at 24617) by debbugs.gnu.org; 28 Dec 2016 20:08:31 +0000
Received: from localhost ([127.0.0.1]:58303 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cMKWU-0002Ob-LR
	for submit <at> debbugs.gnu.org; Wed, 28 Dec 2016 15:08:30 -0500
Received: from mail-wm0-f48.google.com ([74.125.82.48]:34546)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <p.stephani2@HIDDEN>) id 1cMKWS-0002ON-5D
 for 24617 <at> debbugs.gnu.org; Wed, 28 Dec 2016 15:08:28 -0500
Received: by mail-wm0-f48.google.com with SMTP id u144so77089957wmu.1
 for <24617 <at> debbugs.gnu.org>; Wed, 28 Dec 2016 12:08:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=VHm06wrv/7t5OhiElbtRF2oQXvA5koVhZusgY2kDjyM=;
 b=DSmccg67EX3gI/3OCcSuHyvyGIW+U7aiSCQHqkH4FJ5NZTkerbwukfFN3JYqytin2M
 hpGdVFWbS2dluSOrhi+0iq1/KGqHmQsxDXPysM/u8lX7ZoIbNZrNZXS8wFA7mgA2eaZq
 UJRsVf1E5Abi1PcVcqjcx5MZahCQPtQE7ii6gR8DIFLsBeLJQ6GP8iULnuIqaJUqF4Z6
 nRsPOAtqlB6NVwZLNKSGEvgWXe5VZ6Cbx5+r44oQVN3VANfcBO0ntrqec0u66YsoZWCW
 0v+tvC0BdCswxyWMoAbE6VCaVfY9GBq9koeK3QlBNbF6EPZHSrfyFc+h7b657738cm8j
 96TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=VHm06wrv/7t5OhiElbtRF2oQXvA5koVhZusgY2kDjyM=;
 b=WbPQwvVZMksNW1LWkeFeNvBhLuXJ7SsqrhdIfGqLzlnqbTI8ZkBm+BrHIy89KEqhBL
 Zkz/BFpPKMvgqE2jxvSqfFPs5eUDnWx1KknjeVulC2K1sJo8bZxlJyoZNq/pascMnaVc
 NGq7aA6g6eNbWafV/1BcOJk9k3eRmEc6Z+oqo90UcBIhS2261mcYO8V1/DWGL+Wfa9Wi
 8+dTjfylU+NDJnxyI1tHUbH90YVOfKJJSWvZIbnekEuoKBPFjQKmp6bcCG5tz/oL1TIH
 KrmwDKspwFsTa5TV0foxN5BueHjM5Y6q7/zl23mvrjTJysRb61vSxLJFha860kc57CmD
 4V1g==
X-Gm-Message-State: AIkVDXI7tzDOnxWF+3dchrP2Hlqch0cpGvqke76nSJRidNlBzwUf9ademh1QJNILxNI0p1fkY9jhkqrldc+8JQ==
X-Received: by 10.28.129.81 with SMTP id c78mr35696785wmd.94.1482955702522;
 Wed, 28 Dec 2016 12:08:22 -0800 (PST)
MIME-Version: 1.0
References: <wvr4y4249iid.fsf@HIDDEN> <m28tu3z5f5.fsf@HIDDEN>
In-Reply-To: <m28tu3z5f5.fsf@HIDDEN>
From: Philipp Stephani <p.stephani2@HIDDEN>
Date: Wed, 28 Dec 2016 20:08:12 +0000
Message-ID: <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11424262dddbff0544bd8716
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

--001a11424262dddbff0544bd8716
Content-Type: text/plain; charset=UTF-8

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

--001a11424262dddbff0544bd8716
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">Helmut=
 Eller &lt;<a href=3D"mailto:eller.helmut@HIDDEN">eller.helmut@HIDDEN=
</a>&gt; schrieb am Mi., 5. Okt. 2016 um 08:18=C2=A0Uhr:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On Tue, Oct 04 2016, Philipp Stephani wrote:<br class=
=3D"gmail_msg">
<br class=3D"gmail_msg">
&gt; Currently a handler in a `condition-case&#39; form doesn&#39;t have ac=
cess to<br class=3D"gmail_msg">
&gt; the backtrace that was active when the signal was raised.=C2=A0 This m=
akes<br class=3D"gmail_msg">
&gt; many useful things impossible, such as re-raising signals or returning=
<br class=3D"gmail_msg">
&gt; the backtrace to emacsclient.=C2=A0 I suggest either adding true excep=
tion<br class=3D"gmail_msg">
&gt; objects (storing the error symbol, data, and backtrace), or at least<b=
r class=3D"gmail_msg">
&gt; providing a dynamic variable with the current backtrace.<br class=3D"g=
mail_msg">
<br class=3D"gmail_msg">
First, you can copy the backtrace in a signal-hook-function and store it<br=
 class=3D"gmail_msg">
in global variable.<br class=3D"gmail_msg"></blockquote><div><br></div><div=
>Yes, that sounds like a good workaround, with the downside that other libr=
aries might override signal-hook-function and disable that functionality.</=
div><div>Do you know why ERT uses a custom debugger instead of signal-hook-=
function?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class=3D"gmail_msg">
Second, unconditionally copying the backtrace would be expensive </blockquo=
te><div><br></div><div>Are you sure about that? In languages that are typic=
ally far more performance-sensitive (e.g. Java), the backtrace is also copi=
ed unconditionally.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">an=
d<br class=3D"gmail_msg">
would still not allow access to local variables in stack frames or the<br c=
lass=3D"gmail_msg">
value of dynamic variables at the point where the error was signalled<br cl=
ass=3D"gmail_msg">
Just because Java or Python do that doesn&#39;t make it a great idea.<br cl=
ass=3D"gmail_msg"></blockquote><div><br></div><div>True, but having the fun=
ction names and argument values is better than nothing when debugging the c=
ause of a signal.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class=3D"gmail_msg">
Third, the solution to this problem in Common Lisp is the HANDLER-CASE<br c=
lass=3D"gmail_msg">
macro which is similar to condition-case but the error handlers are<br clas=
s=3D"gmail_msg">
executed without unwinding the stack.=C2=A0 That doesn&#39;t require any co=
pying<br class=3D"gmail_msg">
and gives full access to the stack. </blockquote><div><br></div><div>That s=
ounds like an interesting approach that could be made to solve some common =
use cases (e.g. test runners or rethrowing signals).</div></div></div>

--001a11424262dddbff0544bd8716--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: Helmut Eller <eller.helmut@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 29 Dec 2016 09:03:01 +0000
Resent-Message-ID: <handler.24617.B24617.14830021257488 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 24617
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philipp Stephani <p.stephani2@HIDDEN>
Cc: 24617 <at> debbugs.gnu.org
Received: via spool by 24617-submit <at> debbugs.gnu.org id=B24617.14830021257488
          (code B ref 24617); Thu, 29 Dec 2016 09:03:01 +0000
Received: (at 24617) by debbugs.gnu.org; 29 Dec 2016 09:02:05 +0000
Received: from localhost ([127.0.0.1]:58481 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cMWb7-0001wi-FS
	for submit <at> debbugs.gnu.org; Thu, 29 Dec 2016 04:02:05 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:34344)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eller.helmut@HIDDEN>) id 1cMWb5-0001wB-Ep
 for 24617 <at> debbugs.gnu.org; Thu, 29 Dec 2016 04:02:03 -0500
Received: by mail-wm0-f65.google.com with SMTP id c85so27302784wmi.1
 for <24617 <at> debbugs.gnu.org>; Thu, 29 Dec 2016 01:02:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=tkLgdTWg/8ME13FRLH/tklGsJHwkag3zduqGtQZx/I4=;
 b=qeq/whjfFpB8YkiNEUSczChPG77y2WJpGZ2PbEwFzV1TwZtRZVx6OPsG/SqhiilbkW
 c7+OFqhGqcmQjEf440CpVhjc0PFfgtpKumiukfL5757eWJOItsyBCKKc0Va+0TW3AThd
 eDMAVMBKJSJvI40xqkTdrRVoj9H7xWP3cZLepo1IswCb8j28GSn95hnFFkree6SfWZd2
 ZGQhJCJRWLTBtOwtzoxooLMNkizT4mWdWRdT81bM/KuSfemTmrif1DAnvPejquVdM/aj
 GUsKktM3JbToGIr9bWvjBZM0mqBD0fVbpCAhAm+QgzX7LN8j8ImYPZwJC2gufSTrP4ua
 PBmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=tkLgdTWg/8ME13FRLH/tklGsJHwkag3zduqGtQZx/I4=;
 b=NyhQyBNCjzP/QNtJSU7yfvN6yNXQJs8QEh0mZIkrQbuMAfz2+Sgymb8+/JkiGIwzbL
 bYezNYHh8MZs3AgvaTvNXIQvOx+TpXzTf+D+2qZSVIX77wMTUlehphml354LfgzoCX0p
 9h8kxIfYW6oN2E1O6s8jN0gNx76BKnmVQbLXh/hEcphl4dv+sfeS50ECaAzQtQjO4NFd
 fyOjbJOUpJax/ilGGKuHRurUFOOwry1s1eYlg/0ssHhqTLc6bDbH3zMMPEQD3cZ6gLz+
 pGFxAfjMc1bMfFyLUP1XjKkG85L8j982EO0jkdD5McFMv6c6yB08CYtBssI0SbxV0kwT
 9AXw==
X-Gm-Message-State: AIkVDXJSMbFqv6mip+IGCoGs1BX9PTisauJyRWYqGxe4v8TrsAAdSpgYCbExJG5TZ/37+g==
X-Received: by 10.28.109.2 with SMTP id i2mr36284261wmc.41.1483002117558;
 Thu, 29 Dec 2016 01:01:57 -0800 (PST)
Received: from caladan ([212.46.179.89])
 by smtp.gmail.com with ESMTPSA id o132sm64387522wmo.17.2016.12.29.01.01.56
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 29 Dec 2016 01:01:57 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
References: <wvr4y4249iid.fsf@HIDDEN> <m28tu3z5f5.fsf@HIDDEN>
 <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@HIDDEN>
Date: Thu, 29 Dec 2016 10:01:48 +0100
In-Reply-To: <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@HIDDEN>
 (Philipp Stephani's message of "Wed, 28 Dec 2016 20:08:12 +0000")
Message-ID: <m2zijf2jnn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#24617: 26.0.50; Handlers in `condition-case' should have programmatic access to the backtrace
Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 29 Dec 2016 14:04:02 +0000
Resent-Message-ID: <handler.24617.B.148302020810483 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 24617
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 24617 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.148302020810483
          (code B ref -1); Thu, 29 Dec 2016 14:04:02 +0000
Received: (at submit) by debbugs.gnu.org; 29 Dec 2016 14:03:28 +0000
Received: from localhost ([127.0.0.1]:58625 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1cMbIl-0002j0-PA
	for submit <at> debbugs.gnu.org; Thu, 29 Dec 2016 09:03:27 -0500
Received: from eggs.gnu.org ([208.118.235.92]:41210)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <clement.pit@HIDDEN>) id 1cMbIj-0002il-W1
 for submit <at> debbugs.gnu.org; Thu, 29 Dec 2016 09:03:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1cMbIa-0006b2-O2
 for submit <at> debbugs.gnu.org; Thu, 29 Dec 2016 09:03:20 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:58763)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <clement.pit@HIDDEN>)
 id 1cMbIa-0006au-Kf
 for submit <at> debbugs.gnu.org; Thu, 29 Dec 2016 09:03:16 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60413)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1cMbIW-000466-IV
 for bug-gnu-emacs@HIDDEN; Thu, 29 Dec 2016 09:03:16 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <clement.pit@HIDDEN>) id 1cMbIS-0006Yz-Mv
 for bug-gnu-emacs@HIDDEN; Thu, 29 Dec 2016 09:03:12 -0500
Received: from mout.kundenserver.de ([212.227.17.13]:49816)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <clement.pit@HIDDEN>)
 id 1cMbIS-0006YK-91
 for bug-gnu-emacs@HIDDEN; Thu, 29 Dec 2016 09:03:08 -0500
Received: from [192.168.1.79] ([109.24.225.43]) by mrelayeu.kundenserver.de
 (mreue101 [212.227.15.184]) with ESMTPSA (Nemesis) id
 0LrbET-1cWT7F29WP-013Qeo for <bug-gnu-emacs@HIDDEN>; Thu, 29 Dec 2016
 15:03:04 +0100
References: <wvr4y4249iid.fsf@HIDDEN> <m28tu3z5f5.fsf@HIDDEN>
 <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@HIDDEN>
 <m2zijf2jnn.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@HIDDEN>
Message-ID: <f31008ab-ac17-35ea-40aa-7f1a498ffc8f@HIDDEN>
Date: Thu, 29 Dec 2016 15:02:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <m2zijf2jnn.fsf@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="HcbK2uKmpniX9KTILxP57M3Be9F4mJgmA"
X-Provags-ID: V03:K0:yLlrcXxr9a2yl5/+1zGWThJtgg9jPOS3ylIDw6B4D0ENAg9mJmQ
 aNnagBeidtIA46g7QZMz5F4P904Z/23zvPNBM9deDQGYakEYWDPJYOB1hWzZX2A3or/xlsY
 A/VAw1Gm1Wfx9iUNlJFCIDqUAE2t+Zt0b7KezFdudohSKm3BNf5yH0+dJ9Z7tzQypJsPeOf
 G5Zz9ujtqy3//YzofXFYQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:j4cz5eXebwA=:RZQv45dPWsE+/7WjzjTLep
 Pl5ZuHEWiOMDRp0kAiOdIC3TynT8lvmo/ZH+AivVkLZfFyUbqkq/fe9u2zyWpkn9rXOd4DmZh
 rjcwKY3t1Wp6LE0gZGcMvyyKxJDVjTPVCyQJ/MxHT/ECb4jzGrXABBiCynqeXKOi3JmuFSg2w
 H7Npxk7lWNMM6fjAY4UgC8PtbcITxalCCMul2yKms/Qp9fgjxs3THzPH5WEfzKcsxp3127JlY
 lr5Zov0PUM95AetdxsJUxt4pzu8rCsquGjrkzl2jZbflkK1LK+f8XmjlYkyPyodZWuNJuwb3F
 ETW32861xEGWq3C5wYa2CCeC95hU/RuJygQqiL91aW19vvN+lyaKoUA6N1oMhKmbSxRJLD4ua
 l+sWt61dsG5AzunSUnu3LKjCb13mQx3LyoIdSRbtkjTiwalRz9jAOz3IWf7JY8+RnxLxsfeQK
 y6DB7qibuaHvywYetPZ1HLGOP96tvZMTieoh8pzD6P/+x/LtQDXHUWviNjOaZtZihpnGB62GI
 +mV94vaAnTjzPs5YbREKfWKcDfCO9N9II6mtFYdWf4dvP2LcwyQbAD6tP4AIMdhgXNF6DMuEq
 yM3oGi7I3+RpdCOJDrTHfXZkJ6iqBP+ZQiQBOZENXj8+IENFiAeEh4AlRkJEsHyVRWoDLkRGt
 XBTM37WldRAMcBguw7Ayt6TdzcQYqiYulfedn99IEAZhY3smt0fcojRBfuNDw+6w5pzs=
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
 [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HcbK2uKmpniX9KTILxP57M3Be9F4mJgmA
Content-Type: multipart/mixed; boundary="cgq41mktIFq2PR169dhOnDcIkhooF8VL1";
 protected-headers="v1"
From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= <clement.pit@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Message-ID: <f31008ab-ac17-35ea-40aa-7f1a498ffc8f@HIDDEN>
Subject: Re: bug#24617: 26.0.50; Handlers in `condition-case' should have
 programmatic access to the backtrace
References: <wvr4y4249iid.fsf@HIDDEN>
 <m28tu3z5f5.fsf@HIDDEN>
 <CAArVCkTAP5i0T7eAnKL5x81vYA+7nkzK4-7V2T_mBBO7pRcKjg@HIDDEN>
 <m2zijf2jnn.fsf@HIDDEN>
In-Reply-To: <m2zijf2jnn.fsf@HIDDEN>

--cgq41mktIFq2PR169dhOnDcIkhooF8VL1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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 arbitr=
arily 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 quadrati=
c, but I don't know if that matters.  The master branch has mapbacktrace,=
 which solves the quadratic part.

Cl=E9ment.


--cgq41mktIFq2PR169dhOnDcIkhooF8VL1--

--HcbK2uKmpniX9KTILxP57M3Be9F4mJgmA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYZReXAAoJEPqg+cTm90wjEAkP/0C/XELj+Q4Zt9AlEHDTDPnB
rrF+PrMSa66Fq4y7Nuh0frZGEikZKKA1ETjTw+M5LbBGSZ8X3YA13lspAecR3Qcm
cRHNiG1FvWUUUORn2F3zE3bu7WI7VruGpiZoFfFlKF+URC9ARKT9SeubshYsM0ys
xcnHij4phbkazTiN70EkqNN8wm5G5L8XN4vFVCjbSUHOMdMNp3rk2Vl4k1JYAH+J
vzBnBlrMjgZeYvaAnOvDSHvPttKEvVNSGygpYuJWtSqe5fK8V2zyNEq7tLd+OFJW
0jxAdP5V0Y5fk8uy5ea5tcfgCfE7Y+k6sYoRgHjTX69rrMyBNR6Ev6KwKMblRv6I
kPSrPqfGbIvgkfRbecxcy6Y9bT429jaa28ZizYOoQCJ9KeDmTEunPgmaw6Qcb5UV
sIIDPDcb5affoGGONY8BY9uTsMi6oMwDStUl6l0z19dj3lLPJNcDPr2pTPqiMAe/
vkSFiuEPexXLc9emh9zVM8UiifmKoZIV5D6DI0NKvBRVMTTGZILNdhwFFXn/pp8F
DWrlLzWVai2K5Eu0/yGwVRI6MjHwYCtaIa3aZwfm+f4Ht8f6r8UO4y4yoXwEAa9t
eMQeiNQ74dlHpJaHhRma7jgE9mTuY4TU3bmdKNDyAa7A1cVlxfU7oJK+2EWnjkXd
RHGo5lWLI1nWr5z/sJR5
=77EC
-----END PGP SIGNATURE-----

--HcbK2uKmpniX9KTILxP57M3Be9F4mJgmA--

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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