[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gdb doesn't print Lisp backtrace in some circumstances.
From: |
Eli Zaretskii |
Subject: |
Re: gdb doesn't print Lisp backtrace in some circumstances. |
Date: |
Fri, 12 Apr 2024 14:11:04 +0300 |
> Date: Fri, 12 Apr 2024 10:31:53 +0000
> From: Alan Mackenzie <acm@muc.de>
>
> Yesterday I got a core dump from a segmentation fault in Emacs (my
> development version, not master). I loaded this into gdb inside Emacs
> to have a look at it.
>
> The backtrace command output the C data as it should, but on coming to
> the Lisp backtrace gave an error message about there needing to be a
> process running to "do this". (I don't have the exact message any
> more.) It would seem these fancy Lisp facilities only work when the
> process that produced them is still running.
Yes, because they call functions inside Emacs to format Lisp objects.
> All the information required to produce this Lisp backtrace is present
> in the core dump. Would it be possible, perhaps, to modify our .gdbinit
> to use the running Emacs to process the core dump, or something like
> that?
I don't think so, no. But you can reproduce the Lisp backtrace
manually (albeit tediously, by going over all the calls to Ffuncall,
eval_sub and suchlikes, and displaying their arg[0]. If it's a
symbol, typing xsymbol should show you the Lisp function being called.
If it is not a symbol, you could use xcar/xcdr etc., but that is much
more tedious, and I usually give up on those frames in the stack.
Re: gdb doesn't print Lisp backtrace in some circumstances., Gerd Möllmann, 2024/04/12