Re: gdb doesn't print Lisp backtrace in some circumstances.

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

I think it's easier to go through the specbinding stack
(current_thread->m_specdl). For LLDB, I did that in the xbacktrace
function in etc/emacs_lldb.py.