* Need to get Lisp backtrace when error is in C code
@ 2017-10-03 16:43 Robert Weiner
2017-10-03 17:01 ` Eli Zaretskii
2017-10-03 17:50 ` Stefan Monnier
0 siblings, 2 replies; 7+ messages in thread
From: Robert Weiner @ 2017-10-03 16:43 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
Every so often when using Emacs, I get an error from C code similar to this:
let: Wrong type argument: markerp, nil
which gives no indication of where the error is coming from. I have
debug-on-error set to t. I might not have Emacs built with debugging
symbols at times.
Were I to know the source of the error, I could set debug-on-entry to some
Lisp-exposed C function and get a Lisp stack trace to the point of C
function entry. But why can't I have something like this automatically?
The C code is raising an error. The Lisp stack exists. Why can't the C
error routine force the backtrace with some notion that the error exists
further in C code? This would at least narrow down the cause of the error
greatly by showing a lot of the path in code taken.
Personally, for errors like this, I would typically include the function
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?
How do others debug such situations (no C debug symbols)?
Bob
[-- Attachment #2: Type: text/html, Size: 2691 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Need to get Lisp backtrace when error is in C code
2017-10-03 16:43 Need to get Lisp backtrace when error is in C code Robert Weiner
@ 2017-10-03 17:01 ` Eli Zaretskii
2017-10-03 17:50 ` Stefan Monnier
1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2017-10-03 17:01 UTC (permalink / raw)
To: rswgnu; +Cc: emacs-devel
> From: Robert Weiner <rsw@gnu.org>
> Date: Tue, 3 Oct 2017 12:43:20 -0400
>
> How do others debug such situations (no C debug symbols)?
Personally, I never strip Emacs.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Need to get Lisp backtrace when error is in C code
2017-10-03 16:43 Need to get Lisp backtrace when error is in C code Robert Weiner
2017-10-03 17:01 ` Eli Zaretskii
@ 2017-10-03 17:50 ` Stefan Monnier
2017-10-03 18:02 ` Robert Weiner
1 sibling, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2017-10-03 17:50 UTC (permalink / raw)
To: emacs-devel
> Personally, for errors like this, I would typically include the function
> 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.
I guess we could try to replace `Ferror` with a C macro that pushes some
caller-info onto the Lisp backtrace before signaling the error (a bit
like we currently push some pseudo-function onto that stack trace
during garbage collection and redisplay). It won't handle the cases
where we call `Fsignal` instead, nor the cases where we call some
generic C function which then calls Ferror, so to make it really work
well, it'll require more manual work to place the caller-info at the
"right" spot.
Stefan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Need to get Lisp backtrace when error is in C code
2017-10-03 17:50 ` Stefan Monnier
@ 2017-10-03 18:02 ` Robert Weiner
2017-10-03 19:30 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Robert Weiner @ 2017-10-03 18:02 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]
On Tue, Oct 3, 2017 at 1:50 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> > Personally, for errors like this, I would typically include the function
> > 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.
> I guess we could try to replace `Ferror` with a C macro that pushes some
>
> caller-info onto the Lisp backtrace before signaling the error (a bit
>
> like we currently push some pseudo-function onto that stack trace
>
> during garbage collection and redisplay). It won't handle the cases
>
> where we call `Fsignal` instead, nor the cases where we call some
>
> generic C function which then calls Ferror, so to make it really work
>
> well, it'll require more manual work to place the caller-info at the
>
> "right" spot.
>
A full solution would be a big win.
Bob
[-- Attachment #2: Type: text/html, Size: 3196 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-10-04 3:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-03 16:43 Need to get Lisp backtrace when error is in C code Robert Weiner
2017-10-03 17:01 ` Eli Zaretskii
2017-10-03 17:50 ` Stefan Monnier
2017-10-03 18:02 ` Robert Weiner
2017-10-03 19:30 ` Stefan Monnier
2017-10-03 20:58 ` Robert Weiner
2017-10-04 3:25 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).