From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Need to get Lisp backtrace when error is in C code Date: Tue, 3 Oct 2017 14:02:28 -0400 Message-ID: References: Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c071e8e2b981e055aa84db2" X-Trace: blaine.gmane.org 1507053828 13083 195.159.176.226 (3 Oct 2017 18:03:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Oct 2017 18:03:48 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 03 20:03:41 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzRXd-00027X-VB for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 20:03:38 +0200 Original-Received: from localhost ([::1]:59740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzRXj-000357-Mo for ged-emacs-devel@m.gmane.org; Tue, 03 Oct 2017 14:03:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzRX8-00034c-4N for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:03:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzRX2-0006Ms-A0 for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:03:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzRX2-0006Mi-6t for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:03:00 -0400 Original-Received: from mail-qk0-f175.google.com ([209.85.220.175]:50100) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzRX1-0001wf-Sp for emacs-devel@gnu.org; Tue, 03 Oct 2017 14:03:00 -0400 Original-Received: by mail-qk0-f175.google.com with SMTP id u67so9106471qkg.6 for ; Tue, 03 Oct 2017 11:02:59 -0700 (PDT) X-Gm-Message-State: AMCzsaX7sWURoB6EplzFHQtcis32TuPEpx//qcYilB97l0s8wtdtAcsm RHA9IG/bM99b0m0eBAU8O7DHfLIG6/iJTvi3TDc= X-Google-Smtp-Source: AOwi7QC0xp32phU08NrVBorxAg3Axz65xlHPKyqbH1kKWL7w/GqcgKVlPo50UxqnjO3TW8XpaMZDGGgmeezHZFrpAcM= X-Received: by 10.55.137.199 with SMTP id l190mr13493662qkd.156.1507053779258; Tue, 03 Oct 2017 11:02:59 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 11:02:28 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219049 Archived-At: --94eb2c071e8e2b981e055aa84db2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 3, 2017 at 1:50 PM, Stefan Monnier wrote: > > Personally, for errors like this, I would typically include the functio= n > > name reference so that the location is obvious and users without debug > > symbols in their Emacs could still report a more useful error. > > Is this doable? A good idea? > > I think it's desirable, yes. The problem is how to do it. > Even just showing the Lisp backtrace by itself with some note that the error was raised in C code would narrow down the location tremendously I think. =E2=80=8B=E2=80=8B > I guess we could try to replace `Ferror` with a C macro that pushes some > =E2=80=8B=E2=80=8B > caller-info onto the Lisp backtrace before signaling the error (a bit > =E2=80=8B=E2=80=8B > like we currently push some pseudo-function onto that stack trace > =E2=80=8B=E2=80=8B > during garbage collection and redisplay). It won't handle the cases > =E2=80=8B=E2=80=8B > where we call `Fsignal` instead, nor the cases where we call some > =E2=80=8B=E2=80=8B > generic C function which then calls Ferror, so to make it really work > =E2=80=8B=E2=80=8B > well, it'll require more manual work to place the caller-info at the > =E2=80=8B=E2=80=8B > "right" spot. > =E2=80=8BA full solution would be a big win. Bob --94eb2c071e8e2b981e055aa84db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 3, 20= 17 at 1:50 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>= ; Personally, for errors like this, I would typically include the function<= br> > name reference so that the location is obvious and users without debug=
> symbols in their Emacs could still report a more useful error.
> Is this doable?=C2=A0 A good idea?

I think it's desirable, yes.=C2=A0 The problem is how to do it.<= br>

Even just showing the Lisp backtrace by itself w= ith some note that
the error was raised in C code would narrow down the lo= cation tremendously
I think.

=E2=80=8B=E2=80=8B
I guess we could try to replace `Ferror`= with a C macro that pushes some
=E2=80=8B=E2=80=8B
caller-info onto the Lisp backtrace befo= re signaling the error (a bit
=E2=80=8B=E2=80=8B
like we currently push some pseudo-funct= ion onto that stack trace
=E2=80=8B=E2=80=8B
during garbage collection and redisplay)= .=C2=A0 It won't handle the cases
=E2=80=8B=E2=80=8B
where we call `Fsignal` instead, nor the= cases where we call some
=E2=80=8B=E2=80=8B
generic C function which then calls Ferr= or, so to make it really work
=E2=80=8B=E2=80=8B
well, it'll require more manual work= to place the caller-info at the
=E2=80=8B=E2=80=8B
"right" spot.
=

=E2=80=8BA full solution would be a big win.

Bob

--94eb2c071e8e2b981e055aa84db2--